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.
> 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.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
