This is the mail archive of the
mailing list for the GCC project.
Re: Fix IBM long double division inaccuracy (glibc bug 15396)
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>, <dje dot gcc at gmail dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- Date: Sat, 4 Jan 2014 13:28:57 +0000
- Subject: Re: Fix IBM long double division inaccuracy (glibc bug 15396)
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1401022142320 dot 28168 at digraph dot polyomino dot org dot uk> <20140104045358 dot GA31693 at bubble dot grove dot modra dot org>
On Sat, 4 Jan 2014, Alan Modra wrote:
> On Thu, Jan 02, 2014 at 09:46:56PM +0000, Joseph S. Myers wrote:
> > (Note that there remain other bugs in the IBM long double code, some
> > causing glibc test failures, at least (a) invalid results in rounding
> > modes other than FE_TONEAREST, (b) spurious overflow and underflow
> > exceptions, mainly but not entirely where discontiguous mantissa bits
> > are involved.)
> Thing is, the algorithms in rs6000/ibm-ldouble.c require round to
> nearest to generate correct results. Quoting from the PowerPC64 ABI:
Which means that the functions need to set round-to-nearest internally
(maybe only in __gcc_*_round versions used if -frounding-math - one
possibility I suggested in bug 59666 discussing that issue).
> * The software support is restricted to round-to-nearest mode.
> Programs that use extended precision must ensure that this rounding
> mode is in effect when extended-precision calculations are performed.
This is not a valid statement for an ABI to make as it is contrary to the
requirements of ISO C, as I note in bug 59666. When -frounding-math is
used, arithmetic must work in all rounding modes (producing valid results,
not necessarily correctly rounded for non-IEEE formats).
> * Does not support the IEEE status flags for overflow, underflow, and
> other conditions. These flag have no meaning in this format.
The semantics of all except probably "inexact" are perfectly meaningful
for this format.
The glibc libm test results for IBM long double are unfortunately rather a
mess (more so than for other floating-point formats) as various problems
shown up by increased test coverage have languished unfixed for some time
- I'm trying to fix some of the more obvious problems to get to a saner
state of expected failures.
Joseph S. Myers