This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/15852] issues related to floating point precision
- From: "jsm at polyomino dot org dot uk" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 6 Jun 2004 19:35:12 -0000
- Subject: [Bug target/15852] issues related to floating point precision
- References: <20040606180702.15852.sliwa@theta1.cft.edu.pl>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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