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.
I get -2251799813685248 9221120237041090560 vs. -2251799813685248 -2251799813685248 the subtraction is carried out with 4.7, also with 4.6.2.
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
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.
(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?
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.
PS: I don't know whether IEEE says anything about the sign bit, but I doubt it. Brad
(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
> 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. ...
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.
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
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.
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.
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
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).
Confirming still broken as of: xgcc (GCC) 4.8.0 20130108 (experimental) [trunk revision 195030]
Created attachment 52026 [details] CPU and Memorty usage reports for compilling all.i, _num.i, and compiler.i
(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 78249 has been marked as a duplicate of this bug. ***
*** Bug 111655 has been marked as a duplicate of this bug. ***
(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 111655 is not a dup, I left a comment and reopened.
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.)