This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fix sysdeps/ieee754 pow handling of sNaN arguments (bug 20916) [committed]
- From: Stefan Liebler <stli at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Mon, 12 Dec 2016 17:43:04 +0100
- Subject: Re: Fix sysdeps/ieee754 pow handling of sNaN arguments (bug 20916) [committed]
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.2.20.1612022321370.1078@digraph.polyomino.org.uk>
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