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

[Nick Lewycky]

Eli Friedman wrote:
> 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.

How on earth do we do that? ptrtoint is potentially-truncating...

>> 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
>