Optimization o2 vs o3 issue

[John Fine]

Manish Baphna wrote:
>   
> #Line1#    dout.data[15 - count] = (uint8_t)(((long long unsigned int)(*(soc_cpr_dbusdataout_->sig_value_upper)) & (mask << ((8+count)*8)))>>((8+count)*8)); 
> #Line2#    cout << "Dout data " << (uint64_t)((dout.data)[15-count]) << endl;
>
> In US, if we comment 2nd line in RELEASE build (as we should), it FAILS with -o3 switch.  If we put -o2  switch ,it PASSES. We also tried with -finline-functions switch with o2/o3 but it didn't change scene. Unfortunately we use -o3 in our releases. So we are left no option but to have this 'cout' in the code so that it can work.
>
> Seems like its NOT totally unknown issue with GCC4.x family ( we are using gcc4.1.1), some other people Have shared similar griefs.
>   
I  think other people with "similar griefs" were actually seeing 80-bit 
math effects in x86 architecture.  Without the cout, the optimizer might 
keep the value of dout.data[15-count] or some other value from that line 
in an 80 bit register to be used by some subsequent line you didn't 
show.  The 80 bit value wouldn't exactly equal the 64 bit value, so the 
result would change.  If the cout generates an actual call (rather than 
entirely inline) the optimizer can't keep values in 80 bit registers 
across the call.
> Also, just to play around we tried replacing second line with some other lines like
>   
Those make me think you're seeing something different from the common 
80-bit issue.  For that 80-bit issue anything that compiles into a true 
call (not inlined) should be the same correction as anything else that 
compiles into a true call.

> Though we are not stuck due to this , I am keen in finding out the root cause. Also ,are there any other dignified workarounds  other then using o2 switch or having cout in release build ?
>
>   

You really haven't provided enough info to figure this out.

Based on what you have provided, I would guess it is not one of the 
typical optimization issues, such as 80-bit math giving a slightly 
different answer than 64 bit.  I think it is more likely to be a direct 
bug in your code, probably some kind of memory clobber.  In that case 
adding code or changing optimization level or other minor details would 
move things around in memory and change whether a memory clobber hits 
something that matters.  That is, of course, just wild speculation.  You 
haven't provided enough info for anything other than wild speculation.