This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Strange (wrong?) aliasing outcome
- From: Andrew Haley <aph at redhat dot com>
- To: Michael Veksler <VEKSLER at il dot ibm dot com>
- Cc: gcc at gcc dot gnu dot org, Richard Henderson <rth at redhat dot com>
- Date: Tue, 26 Oct 2004 11:46:54 +0100
- Subject: Re: Strange (wrong?) aliasing outcome
- References: <OF7654ACDE.9EF521A1-ONC2256F38.006C7E00-C2256F38.0071C967@il.ibm.com><OF658243F3.4323395C-ONC2256F38.00750086-C2256F38.007591FD@il.ibm.com>
Michael Veksler writes:
>
> Here is another strange example:
>
> struct A { int a; char x;};
> struct B { int b; long x;};
> void f(struct A* pa, struct B*pb)
> {
> pa->a= pb->b+1;
> pa->a= pb->b+1;
> pa->a= pb->b+1;
> pa->a= pb->b+1;
> }
> int main()
> {
> struct A a = {0};
> f(&a, (struct B*)&a);
> return a.a;
> }
>
> I would have thought that f() would be optimized to (like xlC does):
> void f(struct A* pa, struct B*pb)
> {
> pa->a= pb->b+1;
> }
>
> But it is not optimized
It's because the char member of struct A effectively makes its alias
set the same as alias set zero. (Hint: have a look at the way
has_zero_child is used in alias.c.)
This implies that gcc's alias analysis is not complete, but we never
claimed that it was.
Andrew.