From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Thomas Schwinge <thomas@codesourcery.com>
Cc: <libc-alpha@sourceware.org>, <libc-ports@sourceware.org>
Subject: Re: [attention machine maintainers] [PATCH] <math.h> issignaling
Date: Tue, 26 Mar 2013 17:34:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1303261719310.8202@digraph.polyomino.org.uk> (raw)
In-Reply-To: <87r4j73cqo.fsf@schwinge.name>
On Fri, 22 Mar 2013, Thomas Schwinge wrote:
> PowerPC -m64:
>
> math/basic-test.out:
> Failure: double x = (double) (long double) sNaN, !issignaling
>
> That is, this type cast -- which is a IEEE 754-2008 general-computational
> convertFormat operation (IEEE 754-2008, 5.4.2) -- does not turn the sNaN
> into a qNaN (whilst raising an INVALID exception; not checked here),
> which is contrary to IEEE 754-2008 5.1 and 7.2. This I consider a
> compiler issue (powerpc-linux-gnu-gcc (Sourcery CodeBench 2012.09-92)
> 4.7.2).
Such a bug (assuming present in GCC trunk for 4.9) should be filed in GCC
Bugzilla (and I suppose a new math-tests.h macro used to disable the test
in question for older compilers). Though I guess it might only be desired
to change this for -fsignaling-nans.
> MIPS32 O32:
>
> math/test-double.out, math/test-idouble.out:
> Result:
> is: sNaN
> should be: qNaN
>
> Seen for qNaN inputs with: pow, remainder.
The issue for remainder comes from the use of NaN representations in
sysdeps/ieee754/dbl-64/e_remainder.c. In all such cases, for NaN input an
output NaN should be generated by arithmetic involving the inputs, and for
non-NaN input an output NaN should be generated by an arithmetic operation
that generates a NaN and raises INVALID (without other exceptions). The
cases of missing INVALID for this (which only appear with -lieee, so need
testsuite enhancements to test that case in order to be able to test fixes
for them) are bug 14686.
As usual, file bugs with testcases in glibc Bugzilla for the MIPS-specific
problems before fixing them.
> diff --git NEWS NEWS
> index f0965d6..0d70ead 100644
> --- NEWS
> +++ NEWS
> @@ -26,6 +26,8 @@ Version 2.18
>
> * Added a benchmark framework to track performance of functions in glibc.
>
> +* New <math.h> macro named issignaling to check for a signaling NaN (sNaN).
> + This is currently GNU-specific.
"GNU-specific" is a bit misleading there. I think you mean "only defined
if _GNU_SOURCE is defined" (but you should note it comes from draft TS
18661).
> +@comment math.h
> +@comment GNU
> +@deftypefn {Macro} int issignaling (@emph{float-type} @var{x})
> +This macro returns a nonzero value if @var{x} is a signaling NaN
> +(sNaN). It is a GNU extension.
A GNU extension based on draft TS 18661.
> +#undef __issignaling
Why the #undef?
> +int __issignaling (double x)
Return type on a separate line.
Same comments apply to the other implementations.
> +{
> +#ifdef HIGH_ORDER_BIT_IS_SET_FOR_SNAN
> + u_int32_t hxi;
(I tend to think that the C99 names such as uint32_t should be preferred,
but since the libm code seems to be using the legacy names universally,
any such change should probably first be made globally to existing code if
there's consensus, rather than making this code in particular different.)
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2013-03-26 17:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8762148l9v.fsf@schwinge.name>
2013-03-22 11:18 ` Thomas Schwinge
2013-03-24 21:30 ` David Miller
2013-03-25 6:52 ` Thomas Schwinge
2013-03-25 18:39 ` David Miller
2013-03-25 15:54 ` Carlos O'Donell
2013-03-26 17:34 ` Joseph S. Myers [this message]
2013-03-28 12:16 ` Thomas Schwinge
2013-04-03 12:17 ` Thomas Schwinge
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=Pine.LNX.4.64.1303261719310.8202@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=libc-ports@sourceware.org \
--cc=thomas@codesourcery.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).