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

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 12 Dec 2016, Stefan Liebler wrote:

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

TS 18661-1 allows for floating-point assignments and argument passing 
(etc.) to act as convertFormat operations, so converting signaling NaNs to 
quiet.

Obviously when implemented that way, issignaling cannot work reliably.  As 
a quality-of-implementation issue it's probably best to avoid such 
instructions for simple loads of stored values, at least when 
-fsignaling-nans is in use.

So if -fsignaling-nans avoids the issue, compiling pow with 
-fsignaling-nans on s390 would make sense (most of libm isn't built with 
-fsignaling-nans and should still work fine).  Otherwise the tests of 
sNaNs can be disabled in a math-tests.h file for your architecture (like 
sysdeps/i386/fpu/math-tests.h), which should have a comment pointing to a 
bug report in GCC Bugzilla about the issue.

-- 
Joseph S. Myers
joseph@codesourcery.com