BugReportGCC

[Jim Wilson]

colonna@cmapx.polytechnique.fr wrote:
>      3.3-imagine that some instructions later, one have to compare A (now a 64-bit number)
>      and B (still a 80-bit number) ; A is moved from memory to a floating point register
>      and 26 (null) bits are added to it. A and B are no more equal.

This has been a known problem for over a decade.  This is called the 
excess precision problem.  This is partly a problem with the design of 
the x86 FPU, and partly a problem with the design of the gcc x86 
backend.  There is no easy solution in the compiler.  We either write a 
lot of code to handle the x86 FPU, or we lose a lot of performance by 
adding lots of unnecessary rounding operations.  No one has volunteered 
to fix the problem, so it has been left as is for over a decade.

There are various workarounds.
1) Use -ffloat-store which sometimes but not always solves the problem 
with some performance loss.
2) Change the FPU rounding mode from 80-bits to 64-bits.  You no longer 
have access to long-double types, and float types still have excess 
precision problems, but double types will work correctly without any 
performance loss.
3) Perform arithmetic in the SSE registers instead of the x87 FP reg 
stack.  The SSE registers do not have the excess precision problem. 
This requires a recent processor, and a recent gcc version.
4) Use a non-x86 processor.  Only x86 (and old pre-m68040 m68k) have 
this problem.
5) Volunteer to fix gcc (hard).

This is easier to fix in the hardware than in the compiler, but x86 is 
likely to be around for a long time.

Incidentally, AMD64 does not have this problem, because the ABI was 
designed to avoid use of the old x87 FP reg stack.  Hopefully, the same 
will happen with the Intel 64-bit x86 processor.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com