This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
- From: "lucier at math dot purdue.edu" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 08 Dec 2011 20:54:18 +0000
- Subject: [Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
- Auto-submitted: auto-generated
- References: <bug-51446-4@http.gcc.gnu.org/bugzilla/>
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