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


Dale Johannesen <dalej@apple.com> writes:

> On Apr 2, 2004, at 10:18 AM, Geoff Keating wrote:
> >> Restricting p and q to be non-char, it does; *p and *q have
> >> non-compatible types.
> >
> > They have non-compatible types with each other, but that's not the
> > test for whether two things can't alias; the standard talks about the
> > 'effective type of the object'.  So two accesses can alias if there
> > could be a type which is compatible with both of the types involved,
> > even if the two types are not themselves compatible.  If you can work
> > out what the object's effective type is (which is not always possible
> > at compile time, since it's a run-time property) then you could test
> > for compatibility with that, which would be a more precise test.
> 
> OK, I believe that.  Then what we have is a bug.  Do you agree the
> following is standard-conforming?  It gets different results with
> different
> options on ppc; the pointer  derefs in foo have different alias classes,
> and the scheduler does not find a dependency between them.

Yes, I agree, this is conforming:

> unsigned int a, b;
> enum e1 { x, y, z };
> enum e2 {t,u,v};
> void foo (enum e1* e1p, enum e2* e2p, int x)
> { *e1p = x;
>    b = *e2p; }
> 
> main() {
>    enum e1* e1p = (enum e1*) &a;
>    enum e2* e2p = (enum e2*) &a;
>    foo (e1p, e2p, 3);
>    printf("%d\n", b);
> }

It should be easy to fix, just assign enums the same alias set as
their underlying type.

-- 
- Geoffrey Keating <geoffk@geoffk.org>


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