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.
