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

[Thomas Schwinge <thomas at codesourcery dot com>]

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

Attachment: pgpHHlb_8E0RU.pgp
Description: PGP signature