On Tue, 2007-11-06 at 09:37 -0500, Ross Ridge wrote:
> skaller writes:
> > Yes but I still don't understand. The claim was that the assignment
> > might modify p. This is is contra-indicated since p is a pointer
> > to an int, whereas the value being assigned is an int.
>
> The claim was, in the context of the example given, "Without strict
> aliasing being enabled, the compiler can't assume that that the assignment
> 'p[i] = 1' won't change 'p'".
In this case I think it can. More precisely, IF the assignment
changes p, another rules is broken (1 isn't a pointer), and
all bets are off, so the compiler can go ahead and assume
p can't be modified -- on an amd64 anyhow (since int isn't
intptr_t).
However if the example is changed so we have a T* being assigned
to an element of an array of U*, the argument holds (assuming
pointers all have the same representation).
> Another way to put the "strict alias" rule
I do know what the rule means: what I don't understand is
exactly what specifying -fno-strict-aliasing does, i.e. what
would be allowed and what would not.
As the example above shows, aliasing rules aren't the only
way to determine store cannot overlap.
In particular there is a difference between:
int x;
float *px = (float*)(void*)&x;
and
struct X { int a; };
struct Y { int b; };
X x;
Y *px = (Y*)(void*)&x;
In the first case, the compiler can assume no overlap,
and generate optimised code which will not do what you
think because floats and ints aren't layout compatible.
But in the second case X and Y are layout compatible,
guaranteed. So in this case, the compiler can ALSO
generate optimised code that doesn't do what you want
unless -fno-strict-aliasing is specified.
The point is the switch has no effect on the first
case: it can be optimised anyhow, because any code
which can tell the difference necessarily breaks
another rule.
Hope this make sense. Clearly I want the second
case to work as expected, whereas I want the
first case to be optimised no matter what
the -fno-strict-aliasing switch is.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
