[Bug c/14384] Invalid use of extra precision floating-point with -O0 optimization

[wilson at specifixinc dot com]

------- Additional Comments From wilson at specifixinc dot com  2004-03-03 18:52 -------
Subject: Re:  Invalid use of extra precision floating-point with
 -O0 optimization

anz at obs-nice dot fr wrote:
> This source code shows that gcc also keeps extra double precision out of
> functions declared as float, not even honoring the explicit cast (which is
> not needed here by the way).

The gccbug.txt attachment states that this is an x86 target.  So this is 
the classic x86 excess precision problem which has been known for over a 
decade.

This is partly the fault of the x86 FPU, and partly the fault of the gcc 
x86 backend.

The classic x86 FPU has no float or double arithmetic.  It has only long 
double arithmetic.  This means the only way to get the result you want 
is to emit extra instructions to convert results to float or double, but 
this makes the code run slower, and introduces double-rounding errors. 
So there is no way to win here.  Gcc by design emits fast 
excess-precision results.

This is compounded by problems in the gcc backend where it sometimes 
accidently loses the excess precision, resulting in unpredictable 
rounding errors.

There are some things that can be done about this.
1) Use -ffloat-store.  This forces user variables to be rounded but not 
intermediates, so it solves some but not all problems.  This is the 
simplest solution.
2) Set the processor rounding more to float or double instead of the 
default long double.  However, once you set the processor rounding mode, 
you can no longer use larger precisions, so this is useful only if your 
program uses only one precision.  Changing this may break glibc math 
routines.
3) Do arithmetic in the SSE registers instead of the classic FP register 
stack.  The SSE registers have float and double arithmetic instructions, 
and hence do not have the excess precision problem.  This requires 
recent gcc versions and recent x86 processors.  This is probably the 
best solution.
4) Don't use x86 processors for FP work.  This is probably impractical 
for most people though.
5) Fix the gcc backend so that slow double-rounded code is an option. 
This is hard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14384