[BZ #15335] Don't use hard-coded qNaN values in sysdeps/ieee754/dbl-64/e_pow.c:__ieee754_pow
Thomas Schwinge
thomas@codesourcery.com
Thu Apr 4 19:05:00 GMT 2013
Hi!
On Thu, 04 Apr 2013 16:26:17 +0200, Andreas Jaeger <aj@suse.com> wrote:
> On Thursday, April 04, 2013 16:17:45 Thomas Schwinge wrote:
> > On Thu, 04 Apr 2013 09:38:58 +0200, Andreas Jaeger <aj@suse.com>
> wrote:
> > > On Wednesday, April 03, 2013 22:03:31 Thomas Schwinge wrote:
> > > > @@ -139,7 +141,7 @@ __ieee754_pow(double x, double y) {
> > > >
> > > > }
> > > > else if (qx == 0x7ff00000)
> > > >
> > > > return y < 0 ? 0.0 : INF.x;
> > > >
> > > > - return NaNQ.x; /* y not
> > > > integer and x<0 */ + return (x - x) / (x - x);
> > > > /* y not integer and x<0 */>
> > > I'm not convinced of this change, the rest is fine.
> > >
> > > The above raises an invalid exception - but the previous code did
> > > not. Why is this change still fine?
> >
> > If my code and specification reading is correct, then this is a bug in
> > the original code, for IEEE 754-2008 says: »pow (x, y) signals the
> > invalid operation exception for finite x < 0 and finite non-integer
> > y«, and/but this didn't matter in practice, as the wrapper code in
> > math/w_pow.c:__pow would catch this case and handle it separately via
> > sysdeps/ieee754/k_standard.c:__kernel_standard, case 24, raising an
> > INVALID exception on its own. Can you confirm my reasoning?
>
> I wonder whether your change really does, what it should.
>
> You want to pass the same NAN back that was passed in
My primary goal with this patch is to get rid of the hard-coded qNaN bit
pattern, which is wrong for MIPS and HPPA (meaning sNaN for these two).
> kernel_standard always passes a new NAN out. So, shouldn't you change
> k_standard.c accordingly as well?
Getting the payloads of returned NaNs to contain something sensible is a
logically separate change, and will require a lot of modification all
over glibc's math code, and I'm not working on that at the moment. That
I changed some of the dbl-64 pow code from returning a new qNaN to
returning the NaN that was already present as a function input is just
because it was an obvious thing to do for such cases.
> > We could be adding the respective tests to libm-tests with
> > <http://news.gmane.org/find-root.php?message_id=%3C871uaqzheb.fsf%40sc
> > hwinge.name%3E> (or something similar) in place.
>
> libm-tests already checks for the invalid exception,
It does, but only for the default POSIX error handing mode, which is
provided (at least for the case we're discussing here) by
__kernel_standard, case 24, but libm-tests does not check for the right
exceptions being set in IEEE error handling mode, for example.
Grüße,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20130404/54282908/attachment.sig>
More information about the Libc-alpha
mailing list