This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Floating point trouble with x86's extended precision


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
rounding mode.

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
spillage.

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 solution.

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: 6.5.16.1 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 incorrect code.

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.


John.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]