Joe Buck <[EMAIL PROTECTED]> writes:
> On Wed, Nov 07, 2007 at 02:30:44AM +1100, skaller wrote:
> > > 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).
>
> You are implicitly assuming strict aliasing. Strict aliasing means
> that you reject a possible aliasing based on the type, as you are
> doing here (1 isn't a pointer). If you turn it off, the compiler
> cannot make that assumption: the user might be doing something
> strange with casts.
In particular people really do write code like
int addr = 0x12345678;
char* p = (char*)&addr;
*p = 1;
and
int f[2] = { 0x80000000, 0 };
double d = *(double*)f;
This is not valid C/C++ code. But since there is quite a lot of it
out there, the -fno-strict-aliasing rule makes it work correctly.
Ian
