This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Floating point problems (accuracy).
- From: Vincent Lefevre <vincent+gcc at vinc17 dot org>
- To: James E Wilson <wilson at specifixinc dot com>
- Cc: Phil Prentice <philp dot cheer at btinternet dot com>, mike at stec dot clara dot co dot uk,gcc-help at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Wed, 9 Feb 2005 17:16:15 +0100
- Subject: Re: Floating point problems (accuracy).
- References: <E1Cqyvy-00085r-Ad@monty-python.gnu.org> <41ED7E6E.5080905@specifixinc.com>
(This is an old thread, but I've just seen it in the archive.)
On 2005-01-18 13:23:58 -0800, James E Wilson wrote:
> Phil Prentice wrote:
> > We are having a few problems regarding floating point inaccuracies under
> > Linux. Please see the code below.
>
> This is PR 323 in our bug database. One of our most commonly reported
> problems. We call this the excess precision problem.
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
>
> This problem has been known for about 15 years now, and hasn't been
> fixed yet. My suspicion is that it never will be.
Well, this is not a bug. Both the IEEE-754 standard and the ISO C99
standard allow intermediate computations in an extended precision;
however, this is a bad idea in practice. You can read
http://www.vinc17.org/research/extended.en.html
for the various reasons.
But gcc has a real bug concerning the extended precision: it does
not convert the result into double precision (when using the type
"double") after a cast or assignment. Such a conversion is required
by the ISO C standard (see 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2).
There are no reasons not to fix it. For those who fear a performance
loss, gcc could define a compiler switch (that could be included in
-ffast-math).
I know that there have been discussions about this bug, but is there
an entry in the bug tracker?
> Meanwhile, there are a few workarounds
> 1) You can try changing the hardware FP rounding mode to double
> precision. You lose long double support, but you now get correct
> double precision FP. You still have excess precision problems for
> float. This may break libraries (e.g. glibc math library) that
> depend on long double support.
Note that some non-x86 platforms don't have 80-bit arithmetic (i.e.
long double = double, in general). So, such libraries would be
non-portable. The glibc math library is a particular case; I don't
think there's any problem with rounding to IEEE double-precision
though (I'm not sure, and things may have changed). It isn't even
affected by a change of the rounding mode on x86; changing the
rounding mode to a directed rounding mode breaks the math library
on PowerPC and Opteron, for instance.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA