Re: Incorrect bitfield aliasing with Tree SSA

[Laurent GUERBY <laurent at guerby dot net>]

On Sun, 2007-06-17 at 15:31 -0400, Daniel Berlin wrote:
> On 6/17/07, Eric Botcazou <ebotcazou@libertysurf.fr> wrote:
> > > > So if I have
> > > >         struct foo {int x; float y; } bar;
> > > >         int *pi;
> > > >         float *pf;
> > > >
> > > > and mark X as "nonaddressable", I know that an assigment to *pi can't
> > > > affect bar.x.
> > >
> > > 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.
> 
> 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.
> 
> The reality is that a pointer to it's parent can legally access it, so
> their alias sets should conflict.

In Ada if you have a struct type, components of the struct
that do not have the explicit keyword "aliased" cannot
have their adress taken. Example:

type T1 is record
   J : Integer;
end record;

X1 : T1;

=> then X1.J "address" cannot be taken in legal Ada, so no integer
pointer can ever point to it.

type T2 is record
   J : aliased Integer;
end record;

X2 : T2;

=> then X2.J "address" can be taken and integer pointers can point to
it.

I don't think other language have such fine grained control
of adressability attached to the type.

I'm not understanding much of the discussion, just pointing
this language difference out in hope it helps.

Laurent