Re: optimization problem with 1.0.3

[Joe Buck <jbuck at Synopsys dot COM>]

> I'm not sure what to make of this problem.  This simple program
> behaves differently when compiled with or without optimization.

This is a side effect of the Intel floating point hardware.
A double is 64 bits.  The internal floating point registers are 80
bits.  1.0/3.0 has no exact binary representation.  This means that
a 64-bit version of 1/3 will not equal an 80-bit version of 1/3.
Even without this feature, it's dangerous to compare floating
point variables with == or != except in special cases (e.g. where
you know that an exactly representable value has been stored).

If x goes into memory, it gets truncated to 64 bits.  If it stays
in a register, it keeps 80 bits.  Adding extra code evidently
requires x to be spilled to memory.

The -ffloat-store flag will avoid the problem in this case, though
it will slow your program down somewhat.  It forces all floating
point assignments to be truncated to the correct precision.

> --------------
> 
> beefalo% cat egcs_problem_p.c 
> #include <stdio.h>
> 
> int main()
> {
>   int count;
>   double x = 1.0;
>   
>   for(count=0;count<1;count++) {
>     x = x/3.0;
>     if(x != 1.0/3.0)
>       printf("That's odd...\n");
>   }
>   return 0;
> }
> beefalo% gcc egcs_problem_p.c 
> beefalo% a.out 
> beefalo% gcc -g0 -O egcs_problem_p.c
> beefalo% a.out
> That's odd...
> beefalo% gcc -v
> Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/egcs-2.90.29/specs
> gcc version egcs-2.90.29 980515 (egcs-1.0.3 release)
>