[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 Francois-Xavier Coudert changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #17 from Francois-Xavier Coudert --- This is fixed in trunk (will become GCC 12).
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 Francois-Xavier Coudert changed: What|Removed |Added Target Milestone|--- |12.0
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 --- Comment #16 from Francois-Xavier Coudert --- Part 1/3 committed: IEEE_CLASS now recognises signaling NaNs on targets that provide the issignaling macro (from TS 18661-1:2014). https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=492954263e39346287a5a2a32bcc5312466a0ee1
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 Francois-Xavier Coudert changed: What|Removed |Added Attachment #52101|0 |1 is obsolete|| --- Comment #15 from Francois-Xavier Coudert --- Created attachment 52103 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52103&action=edit Patch, v2 Updated patch, passing -fsignaling-nans to the build machinery for IEEE-related runtime files. This fixes the __builtin_nans() issue, and is good practice in any case.
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 --- Comment #14 from Francois-Xavier Coudert --- Created attachment 52101 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52101&action=edit First attempt at a patch This is a first version of a patch for support of signalling NaNs. What it does: - In the code implementing IEEE_CLASS, use the target issignaling macro (from TS 18661-1:2014) to check whether a NaN is signalling. - Sadly, very few targets implement this (I think only glibc targets, currently). This means we will have to provide fallback implementations. A first attempt at fallback implementations is included in the patch, but has not been tested thoroughly. It will require testing on many platforms to be validated. - I moved the library implementation of IEEE_VALUE from Fortran to C code, which gives us access to GCC's built-in functions for NaN generation (both quiet and signalling). What remains to be done: - Write testcases that exercise the different aspects of these functions - Figure out a weird behaviour for __builtin_nanq() in C code: https://gcc.gnu.org/pipermail/gcc/2021-December/237976.html - More testcases :) - Testing the behaviour on different targets Help would be appreciated in finding good testcases.
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |fxcoudert at gcc dot gnu.org --- Comment #13 from Francois-Xavier Coudert --- Let's have a try at fixing this.
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 --- Comment #12 from Steve Kargl --- On Wed, Jun 13, 2018 at 03:55:02PM +, guez at lmd dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 > > --- Comment #11 from Lionel GUEZ --- > And what about my suggestion that ieee_support_nan(0.) should return false for > the time being? > AFAIK, the original implementation for the IEEE support followed either the the F95 Floating-Point Exceptions Tecnical Report (ISO/EIC TR 15580:2001) or F2003. These refer to IEC 60599 (1989-01), aka IEEE 754-1985. Someone needs to review the entirety of the IEEE support with respect to the upcoming F2018 standard. F2018 refers to ISO/IEC/IEEE 60559:2011. I know that 60599:2011 is a significant revision to 60599 (1989-01). Unfortunately, there are not enough "someone"s to go around to fix gfortran. Given a very quick glance at F2003, I think that it may not be a good idea for ieee_support_nan(0.) to return .false. as this then means IEEE_IS_NAN(X) cannot be used to determine if X is a NaN.
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 --- Comment #11 from Lionel GUEZ --- And what about my suggestion that ieee_support_nan(0.) should return false for the time being?
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 --- Comment #10 from Steve Kargl --- n Wed, Jan 24, 2018 at 03:38:10PM +, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 > > --- Comment #9 from Steve Kargl --- > On Wed, Jan 24, 2018 at 10:53:40AM +, guez at lmd dot ens.fr wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 > > > > --- Comment #8 from Lionel GUEZ --- > > It does not seem completely true that gfortran makes no distinction between > > qNaN and sNaN. > > See comment #2. > To be clear. I'm not being dismissive, here. The bug report is still open because there is some agreement that how gfortran handles qNaN and sNaN needs to be revisited. The problem is that there are only a few individuals who actively contribute to gfortran development. There are currently 931 open bug reports. They may not have the time (or perhaps the interest in this issue) given the 930 other problems. If the problem is a significant roadblock for you, then getting involved with gfortran development would be most welcomed. You can ask questions on the fortran@ and gcc@ mailing list. Also, given your email address, you may be able to directly (as in person) discuss the IEEE 754 implementation with Francois-Xavier Coudert (although FX's contributions have diminished over time due to Real Life, ie., wife, kids, job, etc.).
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 --- Comment #9 from Steve Kargl --- On Wed, Jan 24, 2018 at 10:53:40AM +, guez at lmd dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 > > --- Comment #8 from Lionel GUEZ --- > It does not seem completely true that gfortran makes no distinction between > qNaN and sNaN. See comment #2.
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 --- Comment #8 from Lionel GUEZ --- It does not seem completely true that gfortran makes no distinction between qNaN and sNaN. There is the option -finit-real of gfortran with the different possible values nan and snan. Also, there is the option -mnan of gcc which describes different encodings for qnan and snan. Furthermore, I think that, with the present behaviour of gfortran concerning qnan, the function ieee_support_nan(0.) should return false.
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 --- Comment #7 from Steve Kargl --- On Tue, Jan 23, 2018 at 08:53:36PM +, guez at lmd dot ens.fr wrote: > > This behaviour of gfortran is a problem because it prevents the use of qnan as > a normal missing value and the debugging option at the same time. > AFAICT, gfortran make no distinction between qNaN and sNaN. If you use -ffpe-trap=invalid, gfortran will abort. Patches to honor qNaN vs sNaN are welcomed.
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 Lionel GUEZ changed: What|Removed |Added CC||guez at lmd dot ens.fr --- Comment #6 from Lionel GUEZ --- I think this is a bug. A consequence of this bug is that gfortran signals an exception with the option -ffpe-trap=invalid when it encounters a quiet NaN. Here is a test program: $ gfortran --version GNU Fortran (GCC) 7.1.0 $ cat test_qnan.f90 use, intrinsic:: ieee_arithmetic, only: IEEE_SUPPORT_DATATYPE, & ieee_support_nan, ieee_value, IEEE_QUIET_NAN real x if (.not. IEEE_SUPPORT_DATATYPE(0.) .or. .not. ieee_support_nan(0.)) stop 1 x = ieee_value(0., IEEE_QUIET_NAN) end $ gfortran -ffpe-trap=invalid test_qnan.f90 $ a.out Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: #0 0x2b67f141250f in ??? #1 0x2b67f0ad8628 in __ieee_arithmetic_MOD_ieee_value_4 at ../../../libgfortran/ieee/ieee_arithmetic.F90:868 #2 0x4009ae in ??? #3 0x400a01 in ??? #4 0x2b67f13fed1c in ??? #5 0x4007f8 in ??? Floating point exception A quiet NaN should not raise the exception. See for example Adams (2009, The Fortran 2003 Handbook, ยง 14.2.4): "For a processor that supports NaNs and for an operation that returns a floating-point result, a quiet NaN propagates through the operation without raising an invalid exception." For comparison, the ifort compiler behaves correctly here: $ ifort -fpe-all=0 test_qnan.f90 $ a.out produces no error. This behaviour of gfortran is a problem because it prevents the use of qnan as a normal missing value and the debugging option at the same time.
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-09-25 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres --- Confirmed from 5.4.0 up to trunk (8.0), 'ieee_arithmetic.mod' was not implemented before gcc-5.
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to Bill Sacks from comment #3) > Thanks for pointing that out, kargl. I'm fine with this being closed if it's > not actually a bug: it's not causing me any problems, I just happened to > notice it in the course of investigating other aspects of gfortran's NaN > handling. It's a bug that may eventually get addressed. The TODO note affirms that it's a bug. Unfortunately, gfortran is lacking sufficient man-power at the moment to chase down all the bugs. I don't remember if gfortran's IEEE support uses routines covered by fenv.h, but one might be about to use a combination of feclearexcept(), fegetexceptflag(), feraiseexcept(), fesetexceptflag(), and fetestexcept() to get what you want.
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 --- Comment #3 from Bill Sacks --- Thanks for pointing that out, kargl. I'm fine with this being closed if it's not actually a bug: it's not causing me any problems, I just happened to notice it in the course of investigating other aspects of gfortran's NaN handling.
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
--- Comment #2 from kargl at gcc dot gnu.org ---
See gcc/gcc/libgfortran/ieee/ieee_helper.c lines 75-79:
if (res == IEEE_QUIET_NAN) \
{ \
/* TODO: Handle signaling NaNs */ \
return res; \
} \
See also gcc/gcc/libgfortran/ieee/ieee_arithmetic.F90
lines 860-871
elemental real(kind=4) function IEEE_VALUE_4(X, CLASS) result(res)
real(kind=4), intent(in) :: X
type(IEEE_CLASS_TYPE), intent(in) :: CLASS
select case (CLASS%hidden)
case (1) ! IEEE_SIGNALING_NAN
res = -1
res = sqrt(res)
case (2) ! IEEE_QUIET_NAN
res = -1
res = sqrt(res)
It seems gfortran supports NaN, but does not make a distinction
between a quiet and a signal NaN.
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 --- Comment #1 from Bill Sacks --- Created attachment 42166 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42166&action=edit Simple test program Added attachment to demonstrate the problem in a simpler test program. Compile and run with gfortran gfortran_snan.f90 ./a.out
