[LLVMdev] Strange pointer aliasing behaviour

[Eugene Toder]

> Do you have a reference to the standard that makes it undefined?

I'm second this question. I tried to find anything banning calculating
address of one field from address of another in the standard some time
ago, but could not find it.

On Thu, Jun 17, 2010 at 6:19 PM, Jeffrey Yasskin <jyasskin at google.com> wrote:
> On Thu, Jun 17, 2010 at 12:22 AM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Wed, Jun 16, 2010 at 11:14 PM, Pierre C <lists at peufeu.com> wrote:
>>>> There are essentially two ways to "solve" this issue: one is
>>>> type-based alias analysis, i.e. assuming "double" and "int" don't
>>>> alias; LLVM doesn't implement this at the moment.  The other is to
>>>> attempt to analyze the loop and prove that %indvar.i is never
>>>> negative; LLVM doesn't implement anything like this at the moment
>>>> either.
>>>>
>>>> -Eli
>>>
>>> Actually I think it's much simpler than that...
>>>
>>> http://llvm.org/releases/1.3/docs/AliasAnalysis.html#basic-aa
>>>
>>> it says says "Different fields of a structure do not alias."
>>>
>>> This is the case here : we have two different fields of a struct however it
>>> mistakenly thinks they alias.
>>
>> Consider a case like the following:
>> struct X { int a; int b[10]; };
>> int f(struct X* a) { a->b[-1] = 1; return a->a; }
>>
>> This is technically illegal code, but various programs depend on
>> constructs like this working.
>
> I don't know if it's illegal, but this is how libstdc++'s string
> implementation finds its header data. std::string stores a pointer
> directly to the character data (making subscripting slightly faster),
> and then subtracts the size of the header when it needs to do any
> bookkeeping.
>
> Do you have a reference to the standard that makes it undefined?
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>