c/8015: optimization error

[David Relson]

Greetings,

I'm pleased to receive a response to my optimization problem, but quite 
surprised at what you say.  In my 30+ years of software development, 
optimization has always meant getting the same results - just faster or 
using less memory (or some improvement).  It has _never_ meant getting a 
different answer.  Having optimization provide a different answer is, in my 
experience, equivalent to saying "optimization error".

The original program was, of course, much larger than the simplified 
program I sent to you.  Without optimization, it correctly populated a 
(sorted) array and computed the proper bayesian spam result.  With 
optimization, the array is incorrectly populated and an incorrect result is 
produced.

Your suggestion of adding strategically placed "volatile" keywords will 
likely work.  I assert that with correct optimization, it shouldn't be 
necessary to give such clues to the compiler.

Sincerely,

David

At 04:23 PM 11/22/02, reichelt@igpm.rwth-aachen.de wrote:

>Synopsis: optimization error
>
>State-Changed-From-To: open->closed
>State-Changed-By: reichelt
>State-Changed-When: Fri Nov 22 13:23:52 2002
>State-Changed-Why:
>     Not a bug.
>
>     Consider the following simple program:
>
>     int main()
>     {
>         double x=sqrt(2.0);
>         volatile double y=x;
>         if (x<y) printf("Uh oh!\n");
>         return 0;
>     }
>
>     If I compile it with "gcc -O funny.c -lm" I get the output:
>     Uh oh!
>     It's hard to believe at first sight, but that's not a bug.
>     ix86 FPUs do their computations with 80 bit. A double, however,
>     has only 64 bit. So if you store a value from the FPU, you have
>     to round it. If you load it back into the FPU the value might be a
>     different one than before you stored it. That's why x is smaller
>     than y in the above example.
>
>     In your program the same proble occurs with the comparison dev>slotdev.
>     You can try to work around this problem by declaring "dev" and "slotdev"
>     volatile. Then both values always come from memory and you can hope
>     that they underwent the same rounding procedure.
>     Or you could write "dev>slotdev+1e-10" or something similar, to be sure
>     that rounding isn't the reason for the difference between dev and 
> slotdev.
>
>http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8015 
>