Incorrect bitfield aliasing with Tree SSA

[Daniel Berlin]

On 6/17/07, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
> > > > > So if I have
> > > > >         struct foo {int x; float y; } bar;
> > > >
> > > > But if you add
> > > >
> > > > struct foo *foop = &bar.
> > > >
> > > > foop->x = 5.
> > > >
> > > > It can, even though we *claim* X is nonaddressable.
> > >
> > > Which can what exactly?
> >
> > It can be addressed, as i've shown above.  foop is a pointer to &bar.x
> > in the above case.
>
> No, it's a pointer to bar.  It contains the same *value* as a pointer to

>
> bar.x is "nonaddresable" in the sense that any pointer that refers to memory
> contained in it can't be of the type of the field (int) and hence can't
> be of its alias set, but must be of the type of bar (struct foo) and hence
> of *that* alias set.
>
> > The reality is that a pointer to it's parent can legally access it, so
> > their alias sets should conflict.
>
> Which alias sets?  How can a pointer to int conflict with a pointer to bar
> if X is nonaddressable?
That is not the example case we have given where this breaks.
The case where it breaks is exactly the case i have shown you.

We have a pointer to a structure, and because you have not recorded
the type's alias relationships properly, we claim derferences that are
offsetted from the structure can not access the field.
 This is a direct consequence of trying to use the parent's alias set
for that of the child type, instead of creating a new alias set.