Re: Strange (wrong?) aliasing outcome

[Andrew Haley <aph at redhat dot com>]

Michael Veksler writes:
 > 
 > Andrew Haley <aph@redhat.com> wrote on 26/10/2004 12:46:54:
 > 
 > > 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)
 > ....
 > >
 > > 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.
 > 
 > I am not sure this is a complete explanation,

It's a complete explanation of that particular program.

 > as this behavior occurs also with __restrict__ arguments.

 > So as it looks, char is stronger than anything else. Even stronger
 > than an explicit __restrict__:
 > 
 > void f(char * __restrict__ pa, char * __restrict__ pb)
 > {
 >    *pb= *pa+1;
 >    *pb= *pa+1; /* with -O2, gcc should remove this line - but it does not*/
 > }
 > 
 > ---
 > I thought that with 'restrict' alias sets (zero or not) do not matter.

Have a look at alias.c, in particular the section that begins

      /* Check for accesses through restrict-qualified pointers.  */

and 

		    /* For an aggregate, we must treat the restricted
		       pointer...
Andrew.