[Bug target/15852] New: issues related to floating point precision

[Bug target/15852] New: issues related to floating point precision

[sliwa at theta1 dot cft dot edu dot pl]

-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

-- 
           Summary: issues related to floating point precision
           Product: gcc
           Version: 3.3.2
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sliwa at theta1 dot cft dot edu dot pl
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-slackware-linux
  GCC host triplet: i386-slackware-linux
GCC target triplet: i386-slackware-linux


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

[Bug target/15852] issues related to floating point precision

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-06 18:13 -------
Not a bug, read the references in bug 323.

*** This bug has been marked as a duplicate of 323 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


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

[Bug target/15852] issues related to floating point precision

[jsm at polyomino dot org dot uk]

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

[Bug target/15852] issues related to floating point precision

[sliwa at cft dot edu dot pl]

------- Additional Comments From sliwa at cft dot edu dot pl  2004-06-08 18:51 -------
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.


-- 


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