Re: [BZ #15335] Don't use hard-coded qNaN values in sysdeps/ieee754/dbl-64/e_pow.c:__ieee754_pow

[Andreas Jaeger <aj at suse dot com>]

On 04/04/2013 04:59 PM, Thomas Schwinge wrote:
> 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.

Let's get your patch in as is - it's an improvement already.

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

Yes, indeed,

Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 NÃrnberg, Germany
   GF: Jeff Hawn,Jennifer Guild,Felix ImendÃrffer,HRB16746 (AG NÃrnberg)
    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126