turning off optimization on a code segment

turning off optimization on a code segment

[Frédéric BOIS]

Hi!

I have a problem with a code segment (actually one line). If I compile
with no optimization (with or without debugging enabled) it's fine.
If I optimize (again with or without debugging) it fails for one
mis-computed line:
pifn->bOn = (*pdTime < *pdTnext);
if *pdTime is equal to *pdTnext (checked in gdb: print *pdTime -
*pdTnext returns zero and print  (*pdTime < *pdTnext) returns 0 too)
the computed value of pifn->bOn is "1", and that's an error. I don't
know exactly what to do and I am in a rush. I could try to go around 
all that, but an easy quick fix might be to turn off the optimization
of the routine. However, I don't know how to do that.
I get that with gcc 3.3.3 (suze linux), and on v 4.3.0 under debian
linux.

Thanks if you can help.

Frederic

Re: turning off optimization on a code segment

[Andrew Haley]

Frédéric BOIS wrote:
> Hi!
> 
> I have a problem with a code segment (actually one line). If I compile
> with no optimization (with or without debugging enabled) it's fine.
> If I optimize (again with or without debugging) it fails for one
> mis-computed line:
> pifn->bOn = (*pdTime < *pdTnext);
> if *pdTime is equal to *pdTnext (checked in gdb: print *pdTime -
> *pdTnext returns zero and print  (*pdTime < *pdTnext) returns 0 too)
> the computed value of pifn->bOn is "1", and that's an error. I don't
> know exactly what to do and I am in a rush. I could try to go around 
> all that, but an easy quick fix might be to turn off the optimization
> of the routine. However, I don't know how to do that.
> I get that with gcc 3.3.3 (suze linux), and on v 4.3.0 under debian
> linux.

Don't use "gcc -O".  I know you probably want to de-optimize just one 
function, but you can't do that.

However, I'd try to find the real bug.

Andrew.

Re: turning off optimization on a code segment

[John Fine]

If you can't figure out how to turn off optimization for that function, 
you might want to move just the comparison into a non inlined function 
called from that point (passing pointers, not doubles, to that 
function).  In GCC, I'm not sure how to force inlining off, other than 
by the extreme measure of placing the function you don't want inlined in 
a different cpp file.

I expect the underlying problem is that GCC tracked the value of one of 
the two things you're comparing and has that value still in an 80 bit 
register left over from a previous store of that value.  Then the 80 bit 
value does not equal the 64 (or 32)  bit value even if storing the 80 
bit value would create a 64 bit value that is equal.  A non inlined 
routine would force it not to use the left over 80 bit value.  I don't 
know enough about GCC to know what else might force it not to use that.


Frédéric BOIS wrote:
> pifn->bOn = (*pdTime < *pdTnext);
>
>   

Re: turning off optimization on a code segment

[John Fine]

In my first reply, I forgot to include the example I meant to give of 
where I have seen that behavior.  It was a different compiler (not GCC) 
but the issue occurs in any efficient use of the x86 floating point 
stack, so I expect it occurs in GCC as well.

do
{
   *pdTime = *pdTnext;
   invoke some external function
  *pdTnext= some computation
} while ( *pdTime < *pdTnext)

On two successive passes, the exact same 80 bit value is computed for 
*pdTnext, but the loop doesn't end.  The value stored in each of 
*pdTnext  and *pdTime is the 64 bit round of the computed 80 bit value, 
and the value used for *pdTime in the comparison is that 64 bit value, 
but the value used for *pdTnext is the just computed 80 bit value that 
is still available in a register (instead of reading back the value just 
written).  The external function keeps the compiler from tracking the 
value of *pdTime in a register.

I've debugged the above infinite loop a few times in different programs.

Frédéric BOIS wrote:
> pifn->bOn = (*pdTime < *pdTnext);
>   

Re: turning off optimization on a code segment

[Tim Prince]

John Fine wrote:
> In my first reply, I forgot to include the example I meant to give of 
> where I have seen that behavior.  It was a different compiler (not GCC) 
> but the issue occurs in any efficient use of the x86 floating point 
> stack, so I expect it occurs in GCC as well.
> 
> do
> {
>   *pdTime = *pdTnext;
>   invoke some external function
>  *pdTnext= some computation
> } while ( *pdTime < *pdTnext)
> 
> On two successive passes, the exact same 80 bit value is computed for 
> *pdTnext, but the loop doesn't end.  The value stored in each of 
> *pdTnext  and *pdTime is the 64 bit round of the computed 80 bit value, 
> and the value used for *pdTime in the comparison is that 64 bit value, 
> but the value used for *pdTnext is the just computed 80 bit value that 
> is still available in a register (instead of reading back the value just 
> written).  The external function keeps the compiler from tracking the 
> value of *pdTime in a register.
> 
> I've debugged the above infinite loop a few times in different programs.
> 
> Frédéric BOIS wrote:
>> pifn->bOn = (*pdTime < *pdTnext);
>>   

Such a problem could be avoided by several well-known methods:
a) -mfpmath=sse
b) long double *pdTime, *pdTnext
c) -ffloat-store   (more in line with your desire to disable optimization)