This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs


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

Lionel GUEZ <guez at lmd dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |guez at lmd dot ens.fr

--- Comment #6 from Lionel GUEZ <guez at lmd dot ens.fr> ---
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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]