[Bug tree-optimization/51446] New: -fno-trapping-math generates NaN constant with different sign

[Bug tree-optimization/51446] New: -fno-trapping-math generates NaN constant with different sign

[lucier at math dot purdue.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

             Bug #: 51446
           Summary: -fno-trapping-math generates NaN constant with
                    different sign
    Classification: Unclassified
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: lucier@math.purdue.edu


With this compiler:

[Bradley-Luciers-MacBook-Pro:~/Downloads] lucier% /pkgs/gcc-4.6.1/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/pkgs/gcc-4.6.1/bin/gcc
COLLECT_LTO_WRAPPER=/pkgs/gcc-4.6.1/libexec/gcc/x86_64-apple-darwin10.8.0/4.6.1/lto-wrapper
Target: x86_64-apple-darwin10.8.0
Configured with: ../../gcc-4.6.1/configure --prefix=/pkgs/gcc-4.6.1
Thread model: posix
gcc version 4.6.1 (GCC) 

and this code:

#include <stdio.h>
#include <stdlib.h>

int main()
{
  union double_or_long {double d; long l;}
  infinity, nan1, nan2;
  double temp;
  infinity.d = 1.0 / 0.0;
  nan1.d = infinity.d - infinity.d;
  temp = 0.0 / 0.0;
  nan2.d = temp;
  printf("%ld %ld\n", nan1.l, nan2.l);
  return 1;
}

You get

[Bradley-Luciers-MacBook-Pro:~/Downloads] lucier% /pkgs/gcc-4.6.1/bin/gcc -O1
-Wall -W nan-test-c.c
[Bradley-Luciers-MacBook-Pro:~/Downloads] lucier% ./a.out 
-2251799813685248 -2251799813685248
[Bradley-Luciers-MacBook-Pro:~/Downloads] lucier% /pkgs/gcc-4.6.1/bin/gcc -O1
-Wall -W -fno-trapping-math  nan-test-c.c
[Bradley-Luciers-MacBook-Pro:~/Downloads] lucier% ./a.out
9221120237041090560 9221120237041090560

If you look at the assembly, without -fno-trapping-math you get

_main:
LFB4:
        subq    $8, %rsp
LCFI0:
        xorpd   %xmm0, %xmm0
        movsd   LC0(%rip), %xmm1
        divsd   %xmm0, %xmm1
        divsd   %xmm0, %xmm0
        movd    %xmm0, %rdx
        subsd   %xmm1, %xmm1
        movd    %xmm1, %rsi
        leaq    LC2(%rip), %rdi
        movl    $0, %eax
        call    _printf
        movl    $1, %eax
        addq    $8, %rsp
LCFI1:
        ret

i.e., the divisions and subtractions are actually executed; with
-fno-trapping-math you get

_main:
LFB4:
        subq    $8, %rsp
LCFI0:
        movabsq $9221120237041090560, %rdx
        movq    %rdx, %rsi
        leaq    LC0(%rip), %rdi
        movl    $0, %eax
        call    _printf
        movl    $1, %eax
        addq    $8, %rsp
LCFI1:
        ret

i.e., it just loads a constant for both NaNs for which the sign differs from
the value that is computed with the divsd and the subsd instructions.

[Bug tree-optimization/51446] -fno-trapping-math generates NaN constant with different sign

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-07 12:51:39 UTC ---
I get

-2251799813685248 9221120237041090560

vs.

-2251799813685248 -2251799813685248

the subtraction is carried out with 4.7, also with 4.6.2.

[Bug tree-optimization/51446] -fno-trapping-math generates NaN constant with different sign

[lucier at math dot purdue.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

--- Comment #2 from lucier at math dot purdue.edu 2011-12-07 19:55:32 UTC ---
I don't understand what you're saying.

On my linux box

heine:~/Downloads> uname -a
Linux heine 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011 x86_64
x86_64 x86_64 GNU/Linux

and with this compiler:

heine:~/Downloads> /pkgs/gcc-4.6.2/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/pkgs/gcc-4.6.2/bin/gcc
COLLECT_LTO_WRAPPER=/pkgs/gcc-4.6.2/libexec/gcc/x86_64-unknown-linux-gnu/4.6.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc-4.6.2/configure --prefix=/pkgs/gcc-4.6.2
--enable-languages=c --disable-multilib
Thread model: posix
gcc version 4.6.2 (GCC) 

I get exactly the same results as in my initial report.

Do you mean that you get different results with the SVN version of 4.6.2?

Brad

[Bug tree-optimization/51446] -fno-trapping-math generates NaN constant with different sign

[lucier at math dot purdue.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

--- Comment #3 from lucier at math dot purdue.edu 2011-12-07 21:07:09 UTC ---
I've looked through the code in real.c a bit (and perhaps the component of this
bug report should be changed).

It appears that do_divide, when given 0.0/0.0, calls get_canonical_qnan with
sign=0 (line 816 in real.c), but divsd actually returns a qnan with sign bit =
1.

Similarly, do_add when given Inf - Inf, calls get_canonical_qnan with sign bit
= 0 (line 574 of real.c), while subsd returns a qnan with sign bit = 1.

It seems that the sign bit in this situation should be target-dependent if you
want the constants to match what the actual instructions will provide.

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-12-08
          Component|tree-optimization           |middle-end
     Ever Confirmed|0                           |1

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-08 10:10:17 UTC ---
(In reply to comment #3)
> I've looked through the code in real.c a bit (and perhaps the component of this
> bug report should be changed).
> 
> It appears that do_divide, when given 0.0/0.0, calls get_canonical_qnan with
> sign=0 (line 816 in real.c), but divsd actually returns a qnan with sign bit =
> 1.
> 
> Similarly, do_add when given Inf - Inf, calls get_canonical_qnan with sign bit
> = 0 (line 574 of real.c), while subsd returns a qnan with sign bit = 1.
> 
> It seems that the sign bit in this situation should be target-dependent if you
> want the constants to match what the actual instructions will provide.

Interesting.  Does IEEE say anything about the sign of the qnan?  Do the
architecture manuals say anything about the sign of the qnan?

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[lucier at math dot purdue.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

--- Comment #5 from lucier at math dot purdue.edu 2011-12-08 14:30:00 UTC ---
Re:

Do the architecture manuals say anything about the sign of the qnan?

Amazingly enough, they do!

I downloaded the combined x86-64 manuals from

http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-manual-325462-rmver.html

and found the following:

Table 4-3: Floating-point number and NaN encodings:

QNaN Floating-point indefinite: sign is 1

Section 4.8.3.7:

Description of QNaN for floating-point indefinite

Section 8.5.1.2:

0/0, 0*Inf, Inf-Inf, etc., return this QNaN floating-point indefinite.

So at least for Intel x87 processors, the sign bit of the canonical QNaN for
floating-point indefinite should be 1.

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[lucier at math dot purdue.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

--- Comment #6 from lucier at math dot purdue.edu 2011-12-08 14:31:23 UTC ---
PS:  I don't know whether IEEE says anything about the sign bit, but I doubt
it.

Brad

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #7 from kargl at gcc dot gnu.org 2011-12-08 15:29:17 UTC ---
(In reply to comment #6)
> PS:  I don't know whether IEEE says anything about the sign bit, but I doubt
> it.
> 
> Brad


6.3 The Sign Bit

This standard does not interpret the sign of an NaN. 


-- 
steve

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-12-08 16:06:43 UTC ---
> Does IEEE say anything about the sign of the qnan?

>From "Draft 1.2.5 DRAFT Standard for Floating-Point Arithmetic P754 October 4,
2006" at
http://www.validlab.com/754R/drafts/archive/2006-10-04.pdf :

8.2.1 NaN encodings in binary formats
...
All binary NaN bitstrings have all the bits of the biased exponent field E set
to 1 (see 5.4). 
A quiet NaN bitstring should be encoded with the first bit (d1) of the trailing
significand field T being 1. 
A signaling NaN bitstring should be encoded with the first bit of the trailing
significand field being 0. If the first bit of the trailing significand is 0,
some other bit of the trailing significand field must be non-zero to
distinguish the NaN from infinity.

In the preferred encoding, a signaling NaN should be quieted by setting d1 to
1, leaving the remaining bits of T unchanged.
...
8.3 The sign bit 8.3.0

When either an input or result is NaN, this standard does not interpret the
sign of a NaN. Note however that operations on bitstrings – copy, negate, abs,
copySign – specify the sign bit of a NaN result, sometimes based upon the sign
bit of a NaN operand. The logical predicate totalOrder is also affected by the
sign bit of a NaN operand. For all other operations, this standard does not
specify the sign bit of a NaN result, even when there is only one input NaN, or
when the NaN is produced from an invalid operation.
...

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[lucier at math dot purdue.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

--- Comment #9 from lucier at math dot purdue.edu 2011-12-08 17:05:43 UTC ---
Table 4.7 of the

AMD64 Architecture Programmer’s Manual Volume 1:
Application Programming

has a footnote 3 that says

3. The floating-point indefinite value is a QNaN with a negative sign and a
significand whose value is 1.100 ... 000.

Table 4.8 gives the encodings for all the indefinite values again.

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[lucier at math dot purdue.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

--- Comment #10 from lucier at math dot purdue.edu 2011-12-08 18:32:56 UTC ---
Near the end of section 5.3.2 of 

Book E:
Enhanced PowerPC Architecture
Version 1.0
May 7, 2002

it says

Any instruction that generates a QNaN as the result of a disabled Invalid
Operation must generate this QNaN (i.e., 0x7FF8_0000_0000_0000).

The string x7ff8 does not otherwise occur in the manual.

The book

PowerPC User Instruction Set Architecture
Book I
Version 2.02
January 28, 2005

has the same text.

And a small test on my 10-year-old Mac Cube with a G4 powerpc processor shows
that the results have sign bit = 0, i.e., the output is

9221120237041090560 9221120237041090560

So the result is architecture dependent.

Blah.

Brad

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-12-08 18:59:12 UTC ---
find libgcc/config -name sfp-machine.h | xargs grep NANSIGN
shows we already track it for a banch of targets, just in libgcc soft-fp
configuration and not in the compiler itself.  Not sure how accurrate it is on
all targets, but i?86/x86_64/ia64 use negative qNaNs, others positive.

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

--- Comment #12 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-12-08 20:37:11 UTC ---
I think the soft-fp code tries to generate particular target-specific NaNs 
because it's also used in the Linux kernel emulation of floating-point 
instructions - which is a use case where doing the same as particular 
hardware is desirable.

At the level of GCC compiling C code, the compiler provides the language 
semantics.  It doesn't provide the semantics of any particular choice of 
instructions someone might expect to be used to implement the source code 
- and in particular doesn't guarantee any choice of NaN where the language 
(and IEEE 754 as applicable) don't determine the choice of NaN.

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[lucier at math dot purdue.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

--- Comment #13 from lucier at math dot purdue.edu 2011-12-08 20:54:18 UTC ---
On Thu, 2011-12-08 at 20:37 +0000, joseph at codesourcery dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446
> 
> --- Comment #12 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-12-08 20:37:11 UTC ---
> I think the soft-fp code tries to generate particular target-specific NaNs 
> because it's also used in the Linux kernel emulation of floating-point 
> instructions - which is a use case where doing the same as particular 
> hardware is desirable.


Indeed, I couldn't find a place in the gcc sources where this macro was
used:

heine:~/programs/gcc/mainline> grep -R _FP_NANSIGN_Q * | grep -v svn
libgcc/config/ia64/sfp-machine.h:#define _FP_NANSIGN_Q        1
libgcc/config/score/sfp-machine.h:#define _FP_NANSIGN_Q        0
libgcc/config/rs6000/sfp-machine.h:#define _FP_NANSIGN_Q        0
libgcc/config/i386/32/sfp-machine.h:#define _FP_NANSIGN_Q        1
libgcc/config/i386/64/sfp-machine.h:#define _FP_NANSIGN_Q        1
libgcc/config/c6x/sfp-machine.h:#define _FP_NANSIGN_Q        0
libgcc/config/moxie/sfp-machine.h:#define _FP_NANSIGN_Q        0
libgcc/config/lm32/sfp-machine.h:#define _FP_NANSIGN_Q        0
libgcc/config/arm/sfp-machine.h:#define _FP_NANSIGN_Q        0



> At the level of GCC compiling C code, the compiler provides the language 
> semantics.  It doesn't provide the semantics of any particular choice of 
> instructions someone might expect to be used to implement the source code 
> - and in particular doesn't guarantee any choice of NaN where the language 
> (and IEEE 754 as applicable) don't determine the choice of NaN.



I don't think the result of 0./0. in C code on a particular target
should depend on telling the compiler that the runtime library is set up
so that floating-point operations never trap.

Brad

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

--- Comment #14 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-12-08 22:32:24 UTC ---
On Thu, 8 Dec 2011, lucier at math dot purdue.edu wrote:

> Indeed, I couldn't find a place in the gcc sources where this macro was
> used:
> 
> heine:~/programs/gcc/mainline> grep -R _FP_NANSIGN_Q * | grep -v svn

It's used as _FP_NANSIGN_##fs.

> > At the level of GCC compiling C code, the compiler provides the language 
> > semantics.  It doesn't provide the semantics of any particular choice of 
> > instructions someone might expect to be used to implement the source code 
> > - and in particular doesn't guarantee any choice of NaN where the language 
> > (and IEEE 754 as applicable) don't determine the choice of NaN.
> 
> I don't think the result of 0./0. in C code on a particular target
> should depend on telling the compiler that the runtime library is set up
> so that floating-point operations never trap.

This is just the same as other unspecified things like converting an 
out-of-range value from floating-point to integer.  There is no C language 
binding to the processor that defines the result of a/b as being the 
result of some particular divide instruction (and it's quite likely that 
on some processors the choice of NaN could depend e.g. on whether a scalar 
or vector instruction is used); it's only specified as far as the 
language specifies it.  This also allows transformations such as 
converting -1.0*x to -x even if -1.0*x doesn't change the sign of an input 
NaN (negate *is* specified by 754-2008 to change the sign of a NaN).

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[joel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

Joel Sherrill <joel at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joel at gcc dot gnu.org

--- Comment #15 from Joel Sherrill <joel at gcc dot gnu.org> 2013-01-10 01:04:50 UTC ---
Confirming still broken as of:

xgcc (GCC) 4.8.0 20130108 (experimental) [trunk revision 195030]

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

--- Comment #16 from lucier at math dot purdue.edu ---
Created attachment 52026
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52026&action=edit
CPU and Memorty usage reports for compilling all.i, _num.i, and compiler.i

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

--- Comment #17 from lucier at math dot purdue.edu ---
(In reply to lucier from comment #16)
> Created attachment 52026 [details]
> CPU and Memorty usage reports for compilling all.i, _num.i, and compiler.i

Sorry, added comment to wrong PR.

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[roger at nextmovesoftware dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joshua.england@worldprogram
                   |                            |ming.com

--- Comment #18 from Roger Sayle <roger at nextmovesoftware dot com> ---
*** Bug 78249 has been marked as a duplicate of this bug. ***

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eggert at cs dot ucla.edu

--- Comment #19 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 111655 has been marked as a duplicate of this bug. ***

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[eggert at cs dot ucla.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

--- Comment #20 from Paul Eggert <eggert at cs dot ucla.edu> ---
(In reply to joseph@codesourcery.com from comment #14)
> This is just the same as other unspecified things like converting an 
> out-of-range value from floating-point to integer.
No, because when GCC's constant folding disagrees with machine arithmetic, GCC
can generate code that violates the relevant standards.

Here's an example taken from Bug 111655:

  int
  main ()
  {
    double x = 0.0 / 0.0;
    return !__builtin_signbit (x) == !__builtin_signbit (-x);
  }

'main' must return 0 no matter what x's sign happens to be, because "-x" must
flip x's sign bit, so __builtin_signbit(-x) must yield the opposite result from
__builtin_signbit(x). However, this code returns 1 with gcc (GCC) 13.2.1
20230728 (Red Hat 13.2.1-1) on x86-64, compiled with -O2.

The bug occurs because the evaluation of __builtin_signbit (x) is
constant-folded to 0 (under the assumption that 0.0/0.0 yields +NaN), whereas
the evaluation of __builtin_signbit (-x) iuses machine arithmetic to first
calculate 0.0/0.0 (i.e., -NaN), then negate that to +NaN, and then calculate
its sign bit to be 0.

At least for this particular example, GCC is generating the wrong code so this
bug report should be decorated with a "wrong-code" keyword.

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[amonakov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amonakov at gcc dot gnu.org

--- Comment #21 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
Bug 111655 is not a dup, I left a comment and reopened.

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

--- Comment #22 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Mon, 2 Oct 2023, eggert at cs dot ucla.edu via Gcc-bugs wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446
> 
> --- Comment #20 from Paul Eggert <eggert at cs dot ucla.edu> ---
> (In reply to joseph@codesourcery.com from comment #14)
> > This is just the same as other unspecified things like converting an 
> > out-of-range value from floating-point to integer.
> No, because when GCC's constant folding disagrees with machine arithmetic, GCC
> can generate code that violates the relevant standards.

The issue you describe is orthogonal to my comment in this bug.  The 
unspecified cases - both the one I mentioned in my comment and the one in 
the description of this bug - do not require any particular result (choice 
of quiet NaN, choice of value for out-of-range conversion to integer, 
etc.), and in particular do not require a result that could be generated 
by the hardware being used, but they do require that, for each evaluation 
of such an operation in the abstract machine, the implementation behaves 
as if some particular valid choice of result was made for that evaluation; 
wobbly values (some uses of the result behaving as if one choice of value 
were made and other uses behaving as if some other choice were made) are 
not permitted.  (This is similar to the question of whether use of 
uninitialized variables (if not undefined behavior) can produce a wobbly 
value, as such a value naturally results from optimizing a PHI node with 
one uninitialized operand to the value of the other operand.)