strict aliasing (again)

[John Fine]

Mojmir Svoboda wrote:
> by "cant work" - what conditions do you have in mind? whole code is
> compiled with -fno-strict-aliasing -O1 and this works. if it was not,
> it would be spotted long time ago.
>   
Does it fail to work with -O3 -fno-strict-aliasing?

Does it even fail with just -O3 ?
> but there is an awful lot of code *depending* on this so i cannot afford
> complete rewrite i am afraid. so i am trying to find easier ways around
> first.
>   
I think that's the reason -fno-strict-aliasing exists.

I'm not sure how safe it is to make the other questionable assumption in 
that code, that x, y, z and w are laid out in the declared sequence.  I 
think it is OK.

But for the strict aliasing issue, I don't think your operator[] is 
returning an incompatible type, so I don't think that particular pair of 
questionable structures does anything that will actually generate wrong 
code.  I'm pretty sure it makes assumptions that violate the C++ 
standard, but that doesn't necessarily mean any code would be generated 
that does other than what the author of that crap intended.

Even the GetVector3() method doesn't violate strict aliasing, because 
the reference it returns would just be used for x, y, z, and operator[], 
which (from the optimizer's viewpoint) are still just references to the 
same type.