Incorrect bitfield aliasing with Tree SSA

[Daniel Berlin]

On 6/18/07, Daniel Berlin <dberlin@dberlin.org> wrote:
> On 6/18/07, Eric Botcazou <ebotcazou@libertysurf.fr> wrote:
> > > If it was designed properly in the first place, there simply would *be
> > > no problem at the tree level*, because nothing would have broken.
> >
> > That's certainly a point of view.  The other is that the RTL implementation
> > predates the Tree one, works fine in GCC 3.x, including for the C compiler.
> > One would have thought that the Tree implementation would be aware of it
> > instead of overlooking it, given that alias.c is shared among them.
>
> Uh, except as we've discovered, the RTL uses alias set 0, so whatever
> alias set you choose for these doesn't matter anyway to the RTL level.
>
>
> >
> > > So far you guys have resisted what seem like perfectly reasonable
> > > solutions by Adam
> >
> > You mean the patch that would have disabled the whole thing at the RTL level?
> > I'm sure that we can devise something better.
>
> No i mean the idea of making it a different alias set than the parent,
> but a subset of the parent.

also, unique from the alias set of the other type (IE int:31 has a
different alias set than int).