Bug 15852

Summary: issues related to floating point precision
Product: gcc Reporter: sliwa <sliwa>
Component: targetAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED DUPLICATE    
Severity: enhancement CC: gcc-bugs
Priority: P2    
Version: 3.3.2   
Target Milestone: ---   
Host: i386-slackware-linux Target: i386-slackware-linux
Build: i386-slackware-linux Known to work:
Known to fail: Last reconfirmed:

Description sliwa@theta1.cft.edu.pl 2004-06-06 18:07:08 UTC
-ffloat-store requires rewriting existing code. Some libraries, like LAPACK and 
SLATEC, require fp arithmetic at IEEE single/double precision, and are heavily 
affected by the way floating point code is handled by gcc.

In my opinion, these violates pragmatics of the single/double types:

1. floating point conversions do not round the values, e.g. a double converted 
to single remains long double in the register (the conversion is performed only 
on assignment to a variable when -ffloat-store is in effect)

2. comparisons are performed on the long double values from the registers, not 
on the values rounded to the appropriate precision, hence comparison does not 
result in equality, even if it takes place at the appropriate precision level 
(single/double), e.g. 0.1 + 0.4 > 0.5 in floats, altough it's not
Comment 1 Andrew Pinski 2004-06-06 18:13:26 UTC
Not a bug, read the references in bug 323.

*** This bug has been marked as a duplicate of 323 ***
Comment 2 Joseph S. Myers 2004-06-06 19:35:09 UTC
Subject: Re:  issues related to floating point precision

On Sun, 6 Jun 2004, pinskia at gcc dot gnu dot org wrote:

> Not a bug, read the references in bug 323.

You mean "known bug", not "not a bug".  Excess precision is allowed by
C99, and you can even define FLT_EVAL_METHOD to -1 to say that it's
indeterminate when there's excess precision (which at present it is, given
that spills reduce excess precision unpredictably), but we define
FLT_EVAL_METHOD to 2 on x86 (saying that expressions are predictably
evaluated as long double), and even with -ffloat-store we don't follow the
standard rules that conversions to the same or narrower type (by
assignment, cast and (probably) function call and return) get rid of
excess precision (but note that conversions of float to double don't get
rid of excess precision even if the float is being stored with the
precision of long double).  That we don't get rid of excess precision on
casts is clearly a bug, as is the bad definition of FLT_EVAL_METHOD.

Comment 3 sliwa@cft.edu.pl 2004-06-08 18:51:31 UTC
Subject: Re:  issues related to floating point precision


On Sun, Jun 06, 2004 at 07:35:12PM -0000, jsm at polyomino dot org dot uk wrote:
> 
> ------- Additional Comments From jsm at polyomino dot org dot uk  2004-06-06 19:35 -------
> Subject: Re:  issues related to floating point precision
> 
> On Sun, 6 Jun 2004, pinskia at gcc dot gnu dot org wrote:
> 
> > Not a bug, read the references in bug 323.
> 
> You mean "known bug", not "not a bug".  Excess precision is allowed by
> C99, and you can even define FLT_EVAL_METHOD to -1 to say that it's

What about fortran and the comparison issues? It seems that the Intel
compiler takes care of them. Consider this example:

//assume that
float x=0.4, y=0.1; // I mean float values!
//then let
float z=x+y;
//then this is true with -ffloat-store,
// bacause z is chopped to 0.5, whereas x+y not:
if(x+y > z)
  printf("not good...\n");


This issue is the reason for a failure with BLAS test.

BTW, being within the standards does not mean being useful.

Regards,
C.S.


> indeterminate when there's excess precision (which at present it is, given
> that spills reduce excess precision unpredictably), but we define
> FLT_EVAL_METHOD to 2 on x86 (saying that expressions are predictably
> evaluated as long double), and even with -ffloat-store we don't follow the
> standard rules that conversions to the same or narrower type (by
> assignment, cast and (probably) function call and return) get rid of
> excess precision (but note that conversions of float to double don't get
> rid of excess precision even if the float is being stored with the
> precision of long double).  That we don't get rid of excess precision on
> casts is clearly a bug, as is the bad definition of FLT_EVAL_METHOD.
> 
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15852
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.