This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: strict aliasing


Joe Buck <Joe.Buck@synopsys.COM> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]