This is the mail archive of the
mailing list for the GCC project.
Re: Floating point trouble with x86's extended precision
- From: John Vickers <john at xza5 dot com>
- To: Jim Wilson <wilson at tuliptree dot org>
- Cc: Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>, lucier at math dot purdue dot edu, gcc at gcc dot gnu dot org
- Date: Thu, 21 Aug 2003 15:44:09 +0100
- Subject: Re: Floating point trouble with x86's extended precision
- References: <200308201627.h7KGRHaX017733@relay.rwth-aachen.de> <3F43E07B.email@example.com>
Jim Wilson wrote:
> 1) If you care about numerical accuraccy, don't use x86.
Or only ever use long double, maybe ?
2) Do FP arithmetic in the SSE registers via the -mfpmath=sse option. I
haven't tried this myself, so I don't know how practical it is.
Multilibbed Linux ?
3) Set the FP reg rounding precision to 64 bits. This has the flaw that
you can no longer perform XFmode operations. This is only a partial
fix, in that we still have excess precision problems for SFmode operations.
[This has mostly been said before, by folk with more expertise in numerical
computation and/or x87 than myself]
If deterministic results are a goal of GCC, then 80-bit spills are required, even
if some kind of the rounding-mode is set "correctly" for each x87 operation,
since the exponent range of x87 results is always that long double, regardless of
If the rounding is -say- single precision, and intermediate results
exceed the magnitude of the largest representable single precision value,
these intermediate results may have Inf or finite values depending on
If intermediate results fall below the magnitude of the smallest normalised
single precision value, the precision of those intermediate results again
depends on the spillage.
So FLT_EVAL_METHOD==0 or FLT_EVAL_METHOD==1 require something approaching
soft-float on x87.
Even when setting the rounding modes for each operation, GCC might want to have
FLT_EVAL_METHOD == -1.
By "deterministic" I mean something like: if the same floating-point function
in the same translation unit is called more than once with the same inputs,
it returns the same result.
With FLT_EVAL_METHOD == -1, anytime someone complains about weird behaviour,
they can be told that if they had inspected FLT_EVAL_METHOD, they would have
found that the implementation advertised its brokenness, and could they please
be more careful to read the small print in future. NOTABUG.
4) Try using -ffloat-store. This works for some but not all programs.
-ffloat-store forces user declared variables to be allocated on the
stack, and hence avoid the in register excess precision problems.
However, temporaries are still allocated to registers, and can still
cause rounding errors due to excess precision, so this is not a complete
Craig Burley pointed out that this is a strangely named option
back in: http://gcc.gnu.org/ml/gcc/1998-12/msg00133.html (at the end).
With inlining, the rounding errors can be different in different
invocations of the same function, even with -ffloat-store.
If something resembling "-ffloat-store" isn't done, GCC seems to violate
C99 rules for simple assignments: 184.108.40.206 para 2: it's not converting the rvalue
to the type of the lvalue.
5) Fix the x86 backend to stop lying about availability of SFmode/DFmode
operations, probably via an option, since this will reduce performance
so much as to cause other problems.
With the objective of implementing FLT_EVAL_METHOD == 2 ?
Has anyone any tried quantifying the cost ?
How would additional costs arise, appart from wider spills (which are alligned now) ?
This would at least give people the
option of getting slow but correct code instead of the current fast but
Providing they don't rely on library code compiled without "safe" options.
I've found FP bugs in all of the x86 compilers that I've ever used. I
am not sure if there are any that get it right, so I am skeptical that
gcc will ever get it right. I haven't tried any of the compilers from
companies that specialize in FP though, maybe some of them get it right.