skaller <[EMAIL PROTECTED]> writes:
> On Tue, 2007-11-06 at 06:29 -0800, Ian Lance Taylor wrote:
> > skaller <[EMAIL PROTECTED]> writes:
>
> > I recommend that you just read the standard and see the real aliasing
> > rules.
>
> I don't care about that, I'm trying to discover what
> -fno-strict-aliasing actually does.
>
> You hinted that it weakens the rules, without entirely
> disabling type based optimisations.
I have no idea what I hinted. What -fno-strict-aliasing does is turn
off type-based alias analysis. The documentation is accurate.
> > What, other than strict aliasing, tells you that the two types can not
> > be aliased? It is perfectly possible to do a 32-bit write to half of
> > a 64-bit value.
>
> What I'm mainly interested in is how "valid" aliases where
> you write one and read the other will be affected by the
> -fno-strict-aliasing switch.
>
> The code does what it has to, so it doesn't matter what
> the Standard says is allowed and what it says is not:
> what matters is whether I have to use -fno-strict-aliasing
> to ensure my code will work as I expect, and what that
> will cost in terms of optimising unrelated code.
>
> As a contrived example:
>
> void f() {
> struct X { int x; X(int a) : x(a) {} };
> X w(1);
> int *px = (int*)(void*)&w;
> assert( (void*)px == (void*)&w);
> assert( (void*)px == (void*)(&w.x));
> cout << *px << endl;
> }
>
> I expect this to print 1 every time, despite the fact that
> px and &w are pointers to the same store seen as different
> types. I believe the compiler is entitled under strict aliasing
> rules to completely elide the constructor application.
> However the assertions cannot fail.
In this particular case the compiler is likely to act as you expect.
But, yes, in general, you need -fno-strict-aliasing if you want these
kinds of pointer type casts to work as you expect.
Ian
