John Fine wrote:
I only saw the quote, not the original question (because Andrew
replied in a different list than the one in which Hazael asked) so
maybe I missed something, but:
In 32-bit x86 architecture, most floating point operations occur in
80-bit floating point. When stored into memory they are rounded to 32
or 64 bits. But if you enable optimization, some values are never
stored to memory and are used as 80-bit.
I decided to look at your original question at
http://gcc.gnu.org/ml/gcc/2008-11/msg00193.html
Now that I can see more code, everything looks like the optimized answer
before you reversed the multiply should be accurate and the unoptimized
answer as well as the reversed multiply answer should be less accurate.
So when you say the optimized answer is "the wrong result" and the non
optimized is "the expected result" what is your basis for deciding which
result is correct?
Without seeing the full list of numbers, I can't be certain the
optimized result is more accurate. Sometime a local increase in
accuracy causes a global decrease. But for typical tables of values,
your method looks very inaccurate and the optimized code should be
significantly more accurate.
If I'm guessing correctly at the meaning of this code, you accumulate
two large, roughly equal, sums then return the difference between them.
Most of the significance of the difference is lost in rounding while
accumulating the sums.
