IMA vs tree-ssa

[Dale Johannesen]

On Apr 1, 2004, at 4:35 PM, Geoff Keating wrote:

> Dale Johannesen <dalej@apple.com> writes:
>
>> On Mar 8, 2004, at 3:32 PM, Joe Buck wrote:
>>> On Mon, Mar 08, 2004 at 11:57:00PM +0100, Gabriel Dos Reis wrote:
>>>>        [#2] All declarations that  refer  to  the  same  object  or
>>>>        function shall have compatible type; otherwise, the behavior
>>>>        is undefined.
>>> This would seem to suggest that in the situations where 
>>> non-transitive
>>> behavior would otherwise result (for example, an incomplete struct
>>> type is
>>> compatible with two distinct and incompatible definitions of that
>>> struct
>>> type), and this matters (for the purpose of aliasing analysis, for
>>> example), we have undefined behavior, so the compiler should be able 
>>> to
>>> act as though this situation does not arise and assume transitivity.
>>
>> Suppose we have 3 types T1, T2, Tcom such that T1 and T2
>> are not compatible, but Tcom is compatible with either T1 or T2.
>> Let's call the relationship between T1 and T2 "pseudo-compatible".
>> Then:
>>
>> Tcom x;
>> T1 * p = (T1 *)&x;
>> T2 * q = (T2 *)&x;
>>
>> foo()
>> {
>>     T1 x = *p;
>>     *q = ...
>> }
>
> Could you elaborate a bit on this example?  I don't believe you can 
> write
>
>      T1 x = *p;
>      *q = ...
>
> in this case, because one of *p or *q will be incomplete.

Indeed when I wrote this the only examples I could construct used 
multiple
files and IMA.   But see Joseph Myers' response for a single-file case.

>> This is not undefined behavior, and the standard says that p and q
>> don't alias in foo.
>
> It does, that it says that if you write
>
>   p = &x;
>   q = &y;
>
> then you can interchange those two assignments.  It does not, however,
> say that *p and *q don't alias.

Restricting p and q to be non-char, it does; *p and *q have 
non-compatible types.