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

[Eli Friedman]

On Mon, Mar 5, 2012 at 9:35 PM, Nick Lewycky <nicholas at mxc.ca> wrote:
> Eli Friedman wrote:
>>
>> 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.
>
>
> I agree, but IIUC casting pointer to integer doesn't provide any meaning to
> that integer, except for what you get when you cast it back to pointer.

Yes.

> It
> does mean that %ptr1 icmp %ptr2 is not the same as ptrtoint(%ptr1) icmp
> ptrtoint(%ptr2), but that's how I understand the rules.

LLVM currently transforms "ptrtoint(%ptr1) icmp ptrtoint(%ptr2)" to
"%ptr1 icmp %ptr2", so if they aren't equivalent, there's a bug
somewhere.

> I didn't add this rule, this was derived from how LLVM was already treating
> alloca's. If you can demonstrate that this can cause C code to miscompile or
> that we otherwise just don't want to do it, I'll be happy to help be part of
> the fix!

I'll see if I can come up with something.

-Eli