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


On Wed, 20 Aug 2003, Jim Wilson wrote:

> instructions, and this causes unexpected rounding problems.  The easiest 
> way to see this is to write an expression that needs more than 8 
> register to evaluate.  Reload will spill registers in the middle of the 
> expression, and they will be truncated to 64-bits when spilled because 
> the optimizer thinks we have 64-bit values.  This results in rounding 
> error.  The same expression can give different results at different 
> optimization levels because different pseudos get spilled.  This is 
> clearly a gcc bug.  This problem has been known for over a decade, and 

What is clearly a bug here is the definition of FLT_EVAL_METHOD for i387
floating point - which should be -1, not 2, as long as we don't have
80-bit spills (as has been noted before, e.g.  
<http://gcc.gnu.org/ml/gcc/2002-06/msg00561.html>).

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

The first bug in this context would be that it needs to be documented that
-ffloat-store (as well as -std=whatever -pedantic) is needed to get a
conforming implementation: casts and assignments are required (C99 
subclause 6.3.1.5) to remove excess precision.

The second bug would be that this may not always work for casts (we
discard casts to the same type very early, but when there is excess
precision they do have a required effect of removing that excess
precision).

-- 
Joseph S. Myers
jsm@polyomino.org.uk


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