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

[Andreas Jaeger]

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