A quick update, Though I couldn't really found real issue , I found an interesting solution which worked. magic word is 'volatile' :) Original two lines were #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; What I did was inserting this line just above Line#1 volatile uint32_t shift_val = ((8+count)*8) ; and used this in above Line#1 , and then I removed Line#2 and this time it worked. ( First I tried without using 'volatile' and it didn't help ) Another workaround that did the same thing was making count as volatile. These two lines are in for loop which goes for count = 0 to 7 , I don't know why compiler is being lazy here to read it everytime unless I make it volatile. Should it be logged as bug in gcc somewhere ? -Manish --- On Tue, 16/12/08, Manish Baphna <manish_baphna@xxxxxxxxx> wrote: > From: Manish Baphna <manish_baphna@xxxxxxxxx> > Subject: Re: Optimization o2 vs o3 issue > To: "John Fine" <johnsfine@xxxxxxxxxxx> > Cc: gcc-help@xxxxxxxxxxx > Date: Tuesday, 16 December, 2008, 11:26 AM > 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/ Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/
