Re: ada/8606: GNAT floating point optimization bug

[Jim Wilson <wilson at tuliptree dot org>]

kalmquist1@hotmail.com wrote:
> The issue I was raising was a different one:  The value of a variable
> changing over time even though it has not been assigned to.  The code
> I included used the value of the variable named "guess" twice, and
> got two different values.  This is prohibited by the Ada standard.

It is fairly well known that gcc emits incorrect x86 FP code.  This is 
partly a problem with the design of the x86 FPU, and partly a problem 
with the design of the gcc x86 backend.  We call this the "excess 
precision problem".

This problem has been known for over a decade, and hasn't been fixed 
yet.  It probably never will be fixed in gcc.  There are few people 
affected, and even fewer who understand what the problem is.  This is 
also a difficult problem to fix because of the x86 FP design.

-ffloat-store incidentally only papers over the problem.  It forces user 
declared variables to be allocated to memory, which avoids the excess 
precision problem for them.  However, temporaries are still allocated to 
registers, and hence you can still see a problem with some programs even 
when -ffloat-store is used.

If you must use x86 processors for FP code, then you should look into 
using SSE registers instead of the traditional x87 FP register stack. 
The SSE registers do not have the excess precision problem.  You can get 
FP to use the SSE registers by using the -mfpmath=sse option.  The AMD64 
people by the way have apparently permanently solved the problem by 
changing the ABI to require use of the SSE registers.

The underlying gcc problem here is that the x86 gcc backend lies, and 
claims that it has SFmode/DFmode instructions.  Gcc then thinks that 
there are SFmode/DFmode values in FP registers, but they are actually 
80-bit values.  This excess precision is relatively harmless for most FP 
algorithms.  The real problem here though is when the register allocator 
needs to spill a value to the stack.  It spills a SFmode/DFmode value, 
because that is what it thinks is in the register.  This means that 
80-bit values get accidentally truncated to SFmode/DFmode values at 
unpredictable places in the code.  This can cause havoc even for well 
behaved FP algorithms.

Jim