Incorrect bitfield aliasing with Tree SSA

[Richard Kenner]

> > > > 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 would, but is of the wrong type.

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?

> You guys seem to be trying to get some sort of optimization through
> hacking around with the alias set system, and then guessing at how all
> the clients will actually use the information.

Not at all.  This is completely consistent.  No hacking or lying to the
type system involved!