Hi John
Thanx for detaild reply.
About info, well, I thought I provided required enough but I might be wrong :)
Let me know what all information you need further.
I can provide that.
And about memory issue , yes , you may be right that there might be some bug in our code but then why this issue is coming in release build in Austin in not in India ?
Also ,we have tried valgrind on this code , though I found valgrind horribly-non-friendly I couldn't see any critical errror out of that.
Though ,I still don't deny possibility of some complex memory clobber. just that I want to catch it somehow !
BestRegards,
Manish
--- On Mon, 15/12/08, John Fine <johnsfine@xxxxxxxxxxx> wrote:
> From: John Fine <johnsfine@xxxxxxxxxxx>
> Subject: Re: Optimization o2 vs o3 issue
> To: manish_baphna@xxxxxxxxx
> Cc: gcc-help@xxxxxxxxxxx
> Date: Monday, 15 December, 2008, 8:10 PM
> 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.
Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/
