This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: IMA vs tree-ssa



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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]