Re: Fix sysdeps/ieee754 pow handling of sNaN arguments (bug 20916) [committed]

[Stefan Liebler <stli@linux.vnet.ibm.com>]

On 12/03/2016 12:21 AM, Joseph Myers wrote:
> Various pow function implementations mishandle sNaN arguments in
> various ways.  This includes returning sNaN instead of qNaN for sNaN
> arguments.  For arguments (1, sNaN) and (sNaN, 0), TS 18661-1
> semantics are also that the result should be qNaN, whereas with a qNaN
> argument there the result should be 1, but for the dbl-64
> implementation of pow there are issues with sNaN arguments beyond not
> implementing the TS 18661-1 semantics in those special cases.
>
> This patch makes the implementations in sysdeps/ieee754 follow the TS
> 18661-1 semantics consistently.  Because x86 / x86_64 implementations
> still need fixing, testcases are not included with this patch; they
> will be included with the fix for the x86 / x86_64 versions.
>
> Tested for x86_64, x86, mips64 and powerpc (with such testcases, which
> pass in the mips64 and powerpc cases).  Committed.

Hi Joseph,
on s390, I get test fails in math/test-double / math/test-idouble:
testing double (without inline functions)
Failure: Test: pow (1, sNaN)
Result:
  is:          1.0000000000000000e+00   0x1.0000000000000p+0
  should be:  qNaN
Failure: Test: pow (1, -sNaN)
Result:
  is:          1.0000000000000000e+00   0x1.0000000000000p+0
  should be:  qNaN
Failure: Test: pow_downward (1, sNaN)
Result:
  is:          1.0000000000000000e+00   0x1.0000000000000p+0
  should be:  qNaN
Failure: Test: pow_downward (1, -sNaN)
Result:
  is:          1.0000000000000000e+00   0x1.0000000000000p+0
  should be:  qNaN
Failure: Test: pow_towardzero (1, sNaN)
Result:
  is:          1.0000000000000000e+00   0x1.0000000000000p+0
  should be:  qNaN
Failure: Test: pow_towardzero (1, -sNaN)
Result:
  is:          1.0000000000000000e+00   0x1.0000000000000p+0
  should be:  qNaN
Failure: Test: pow_upward (1, sNaN)
Result:
  is:          1.0000000000000000e+00   0x1.0000000000000p+0
  should be:  qNaN
Failure: Test: pow_upward (1, -sNaN)
Result:
  is:          1.0000000000000000e+00   0x1.0000000000000p+0
  should be:  qNaN

Test suite completed:
   97258 test cases plus 86314 tests for exception flags and
     86314 tests for errno executed.
   8 errors occurred.


I've debugged in sysdeps/ieee754/dbl-64/e_pow.c and recognized that sNaN 
is converted to qNaN in line 85:
       if (y == 0)
	return 1.0;
This comparison is done with a load-and-test instruction from and to the 
same register, which results in a qNaN.
This value is passed to issignaling (y) in line 148:
   if (qy >= 0x7ff00000 && (qy > 0x7ff00000 || v.i[LOW_HALF] != 0))	/* 
NaN */
     return x == 1.0 && !issignaling (y) ? 1.0 : y + y;


 From ieee 754-2008 "6.2 Operations with NaNs":
"Under default exception handling, any operation signaling an invalid 
operation exception and for which a floating-point result is to be 
delivered shall deliver a quiet NaN."

As the used load-and-test instruction delivers a result, I think qNaN is 
correct. But is the compiler allowed to use this instruction for a 
comparision against zero?

How can I get rid of this issue?
Shall I use "if ((v.i[HIGH_HALF] & 0x7fffffff) == 0x0)" on s390?

Bye
Stefan