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.
