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]
On Tue, Dec 13, 2016 at 09:42:14PM +0000, Joseph Myers wrote:
> 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.
The problem with the load and test instruction is that it is not
consistent to doing a load and a compare separately. Our floating
point loads do not quiet a NaN.
While the IEEE standard leaves it open to quiet NaNs with loads it is
probably supposed to be the same for all loads.
The plan is to disable the use of the FPR result of a load-and-test
instruction in the compiler. We would leave the Glibc tests failing
since this appears to be a real finding to me.
Does this sound reasonable?
-Andreas-