public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
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

  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).