Re: Type Punning and -O3 on gcc 4.8.1 and 4.8.2

[Andy Schneider <andrew_schneider_uk at yahoo dot co dot uk>]

> consider using a free web-based e-mail account 

Done

>Please send us a test case that we can run.


I'm currently unable to create a test case that doesn't pull with it a whole string of dependencies. Trivial mutations to the code result in the issue dissapearing. Given that, I thought I'd ask the more general question which was "is this code unsafe in gcc 4.8?". If it's considered unsafe I can fix that code. If it's considered safe and it's not a known issue then it's worth me spending more time trying to construct a test case. 

Additionally, if there are some diagnostics that might help me debug this type of issue, please let me know. 

Andy

-----Original Message-----
From: Andrew Haley [mailto:aph@redhat.com]
Sent: Thursday, November 14, 2013 11:11 AM
To: Andy Schneider
Cc: gcc-help@gcc.gnu.org
Subject: Re: Type Punning and -O3 on gcc 4.8.1 and 4.8.2

On 11/14/2013 10:54 AM, Andy Schneider wrote:
> Is the above unsafe on gcc 4.8? Have I tripped up over a known issue?

Please send us a test case that we can run.

And we can't read emails that have confidentiality notices.  Such disclaimers are inappropriate for mail sent to public lists. If your company automatically adds something like this to outgoing mail, and you can't convince them to stop, you might consider using a free web-based e-mail account.

Andrew.

-----Original Message-----
From: Andy Schneider 

Hi, I have some code that computes a result from values in the type punning struct below. The struct is initialised with a 64 bit integer and the computations use the values of l1 and l2, i.e. it relies on type punning. The computation accesses all members via the union. 

struct pun 
{ 
    union 
    { 
        struct { uint32_t l1; uint32_t l2; }; 
        uint64_t v; 
    }; 

    pun (uint64_t v) : v(v) { } 
};

When I compile my code thus: 

g++ -std=c++0x -g  -fnon-call-exceptions -fasynchronous-unwind-tables -ffast-math -msse4 -MMD -O3 -fno-threadsafe-statics -fno-omit-frame-pointer --param inline-unit-growth=70 -Wstrict-aliasing -Wformat -Werror=format -Wno-multichar -Werror=sequence-point -Werror=overflow -Werror=nonnull -Werror=return-type -Werror=unused-function -Werror=array-bounds 

there are instances when the compiler chooses to pre-compute the value at compile time, which is nice. Unfortunately the resulting value doesn't match the result of executing the same computation at run-time. It appears that the value at compile time is the value that would be derived if l2 (above) was zero rather than the non-zero value it takes in this instance. I've read http://gcc.gnu.org/onlinedocs/gcc-4.4.1/gcc/Optimize-Options.html#Type_002dpunning which I interpret as meaning the above is ok. Is the above unsafe on gcc 4.8? Have I tripped up over a known issue? 

Andy