From: Joseph Myers <joseph@codesourcery.com>
To: Stefan Liebler <stli@linux.vnet.ibm.com>
Cc: <libc-alpha@sourceware.org>
Subject: Re: Fix sysdeps/ieee754 pow handling of sNaN arguments (bug 20916) [committed]
Date: Tue, 13 Dec 2016 21:42:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.20.1612132135260.20484@digraph.polyomino.org.uk> (raw)
In-Reply-To: <f3864388-4e9f-73ce-b028-90496fd253cf@linux.vnet.ibm.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
next prev parent reply other threads:[~2016-12-13 21:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-02 23:22 Joseph Myers
2016-12-12 16:43 ` Stefan Liebler
2016-12-13 21:42 ` Joseph Myers [this message]
2016-12-14 9:54 ` Andreas Krebbel
2016-12-14 17:22 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1612132135260.20484@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=stli@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).