Bug 81120 - __builtin_nansl ("") generates quiet NaN
Summary: __builtin_nansl ("") generates quiet NaN
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 6.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-17 20:16 UTC by John David Anglin
Modified: 2017-06-20 12:15 UTC (History)
1 user (show)

See Also:
Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
Build: hppa-unknown-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John David Anglin 2017-06-17 20:16:39 UTC
The following code fails because __builtin_nansl generates a quiet NaN:

extern int __issignaling (double);
int
main (void)
{
  double sNaN = __builtin_nansl ("");
  if (!__issignaling(sNaN))
    return 1;
  return 0;
}

.LC0:
        .word   2146959359
        .word   -1

(gdb) p/x 2146959359
$1 = 0x7ff7ffff

This is a quiet NaN on PA-RISC.

__builtin_nans() correctly generates a signaling NaN.

long double and double are the same on hppa-linux.

The problem causes several glibc testsuite failures.
Comment 1 John David Anglin 2017-06-17 22:52:46 UTC
This seems quite tricky.  Conversion changes a signaling nan to a quiet nan:

  /* Make resulting NaN value to be qNaN. The caller has the
     responsibility to avoid the operation if flag_signaling_nans
     is on.  */
  if (r->cl == rvc_nan)
    r->signalling = 0;

But the following results in a signaling nan:

extern int __issignaling (double);
int
main (void)
{
  long double sNaN = __builtin_nansl ("");
  if (!__issignaling((double)sNaN))
    return 1;
  return 0;
}
Comment 2 John David Anglin 2017-06-17 23:49:19 UTC
If the original testcase is compiled with -fsignaling-nans, the signaling
nan is not converted to a quiet nan.  Thus, I believe the conversion is
expected.

There might be an issue with the second testcase.
Comment 3 jsm-csl@polyomino.org.uk 2017-06-19 17:32:03 UTC
Of course, such a test is fairly meaningless without -fsignaling-nans.

Then, where long double and double have the same format, "Whether C 
assignment (6.5.16) (and conversion as if by assignment) to the same 
format is an IEC 60559 convertFormat or copy operation is 
implementation-defined, even if <fenv.h> defines the macro 
FE_SNANS_ALWAYS_SIGNAL (F.2.1)." from TS 18661-1 applies.  That is, a test 
should not be expecting a particular choice of the signaling NaN being 
quieted or not by a conversion to the same format, including when that's a 
conversion from long double to double (and GCC will generally not quiet 
the signaling NaN in such a conversion, unless on an excess-precision 
architecture where simple loads of the narrower type quiet it).
Comment 4 dave.anglin 2017-06-19 18:07:07 UTC
On 2017-06-19 1:32 PM, joseph at codesourcery dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81120
>
> --- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
> Of course, such a test is fairly meaningless without -fsignaling-nans.
The failing glibc tests mentioned in math/21607 do not have 
-fsignaling-nans but adding
it didn't affect the result for basic-test.  Need to simplify the test 
to get an accurate testcase.
>
> Then, where long double and double have the same format, "Whether C
> assignment (6.5.16) (and conversion as if by assignment) to the same
> format is an IEC 60559 convertFormat or copy operation is
> implementation-defined, even if <fenv.h> defines the macro
Is there a gcc option to select between convertFormat and copy? Loads do 
not quiet signaling
NaNs on PA-RISC, so I think a "copy" operation would be preferred. I 
believe __issignaling() is
used for both double and long double in hppa glibc.
Comment 5 jsm-csl@polyomino.org.uk 2017-06-19 20:31:37 UTC
On Mon, 19 Jun 2017, dave.anglin at bell dot net wrote:

> Is there a gcc option to select between convertFormat and copy? Loads do 

There is no such option.
Comment 6 John David Anglin 2017-06-20 12:15:22 UTC
Given Joseph's comments, closing.