[llvm-commits] [llvm] r151710 - /llvm/trunk/docs/LangRef.html

[Eli Friedman]

On Wed, Feb 29, 2012 at 12:26 AM, Nick Lewycky <nicholas at mxc.ca> wrote:
> Author: nicholas
> Date: Wed Feb 29 02:26:44 2012
> New Revision: 151710
>
> URL: http://llvm.org/viewvc/llvm-project?rev=151710&view=rev
> Log:
> Where the alloca'd space actually lives in ram is undefined, and attempting to
> pin it down is undefined behaviour.
>
> Modified:
>    llvm/trunk/docs/LangRef.html
>
> Modified: llvm/trunk/docs/LangRef.html
> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/LangRef.html?rev=151710&r1=151709&r2=151710&view=diff
> ==============================================================================
> --- llvm/trunk/docs/LangRef.html (original)
> +++ llvm/trunk/docs/LangRef.html Wed Feb 29 02:26:44 2012
> @@ -4859,7 +4859,12 @@
>    variables that must have an address available.  When the function returns
>    (either with the <tt><a href="#i_ret">ret</a></tt>
>    or <tt><a href="#i_resume">resume</a></tt> instructions), the memory is
> -   reclaimed.  Allocating zero bytes is legal, but the result is undefined.</p>
> +   reclaimed.  Allocating zero bytes is legal, but the result is undefined.
> +   The order in which memory is allocated (ie., which way the stack grows) is
> +   not specified, and relational comparisons involving '<tt>alloca</tt>'s are
> +   undefined.</p>

This is really aggressive.  In fact, I think it's actually more
aggressive than the C standard actually allows, given that we
implement local variables with alloca.  Specifically, C allows casting
a pointer to an integer, and all operations on that integer are
well-defined.

-Eli