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

[Eli Friedman]

On Mon, Mar 5, 2012 at 9:50 PM, Nick Lewycky <nicholas at mxc.ca> wrote:
> 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 think we only do it if the width matches.

BTW, a case where we screw up following; compile at -O1 on x86-64.
It's a bit contrived, but we manage to trigger an assertion for a
condition which should be impossible, and I'm pretty sure this program
doesn't actually do anything undefined:

#include <stddef.h>
#include <assert.h>
union pi { int* a; size_t b; };
size_t bad(union pi a, size_t* b) {
  int *x;
  size_t xp = (size_t)&x;
  if (a.b != xp)
    assert(*b != xp);
  return (size_t)&x;
}
int main() {
  union pi p = { 0 };
  p.b = bad(p, &p.b);
  bad(p, &p.b);
}

-Eli