Re: strict aliasing (again)

[Mojmir Svoboda <mojmir dot svoboda at illusionsoftworks dot com>]

* John Fine <johnsfine@verizon.net> [2008-12-02 08:21:34 -0500]:

> Does it fail to work with -O3 -fno-strict-aliasing?
> Does it even fail with just -O3 ?

i have to try.. had already problems even with -O2 at some places really ;)

>> 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.

if i understand it correctly, the options apply per .o file. so i have
to move the puning code in a .cpp file if i want to enable strict
aliasing anywhere else, don't i?

> 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.  

apparently this is the case, but i do not like the idea of relying on that.

sometimes i am like alice in neverwhere, what can get through compiler and
still work, for example:

    struct some_base {
        virtual int id () = 0;
    };
    struct bar : some_base { int id () { return 1; } };
    void foo (int id) { }
    #define REG(aa) foo(((aa*)0L)->aa::id())

is that code harmless from your viewpoint? actually, how come the code emitted
works at all? :)

> 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.

> 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.

for you perhaps it's evident, but being an user i have to rely on standard.
if standard says that's an undefined or implementation defined behaviour than
i'd rather kick this code out.

> 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.

you mean "does not violate" from the viewpoint of optimizer, do you?
and what if you later take address of the returned reference from GetVector3()
and work with that, still ok?

best regards,
mojmir