On 6/17/07, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
On Sun, 2007-06-17 at 15:31 -0400, Daniel Berlin wrote: > On 6/17/07, Eric Botcazou <[EMAIL PROTECTED]> 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.
However, can a pointer to X1, stored into, affect J? If so, field J's alias set must be marked as a subset of X1's alias set, or we will get the info wrong. We currently do *not* mark field J's alias set as a subset of X1's, because J is DECL_NONADDRESSABLE_P. (This is in fact, the problem we are hitting here in C. We do *not* record the alias as a subset, which in effect, claims a pointer to the structure can never touch the field, which is wrong. The correct place for such optimization is to do it per-memory reference, not to screw up the type based info)
