Re: Strange (wrong?) aliasing outcome

[Michael Veksler <VEKSLER at il dot ibm dot com>]

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, as this behavior occurs
also with __restrict__ arguments.
The following experiment does match your explanation though:

struct A{ int a; };
struct B { int b; };
void f(struct A*  pa, struct B* pb)
{
   pb->b= pa->a+1;
   pb->b= pa->a+1; /* with -O2, the compiler removes this line */
}

---
Also, __restrict__ works as expected as long as there is no 'char'
in the struct:

void f(int * __restrict__ pa, int * __restrict__ pb)
{
   *pb= *pa+1;
   *pb= *pa+1; /* with -O2, the compiler removes this line */
}

---
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.