------- Comment #4 from burnus at gcc dot gnu dot org 2007-05-22 23:02 ------- Fortran has no concept of NaN except in Fortran 2003 IEEE module. To say it in the words of Dick Hendrickson (cf. PR 30694): "A program is prohibited from invoking an intrinsic procedure under circumstances where a value to be returned in a subroutine argument or function result is outside the range of values representable by objects of the specified type and type parameters, unless the intrinsic module IEEE_ARITHMETIC (section 14) is accessible and there is support for an infinite or a NaN result, as appropriate."
If NaN is supported, then the compiler should follow IEEE which defines: http://754r.ucbtest.org/drafts/754r.pdf "minNum(x,y) is the canonical floating-point number x if x < y, y if y < x, the canonicalized floating-point number if one operand is a floating-point number and the other a NaN. Otherwise it is either x or y. maxNum(x,y) is the canonical floating-point number y if x < y, x if y < x, the canonicalized floating-point number if one operand is a floating-point number and the other a NaN. Otherwise it is either x or y." Thus the example program should be 2.100000 in both cases. Other compilers: - g95: NaN, NaN -> not IEEE conform - NAG f95: NaN, 2.0999999 -> not consistent, not IEEE conform - gfortran: 2.100000, NaN -> not consistent, not IEEE conform - ifort 9.1: NaN, 2.100000 -> not consistent, not IEEE conform - sunf95: -NaN, 2.1 -> not consistent, not IEEE conform > And NaN is unordered which causes the results to become undefined unless you > have a defined value for min/max in the standard Fortran has - albeit only indirectly via the IEEE support. -- burnus at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |burnus at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32048
