diff options
| author | Janne Blomqvist <jb@gcc.gnu.org> | 2018-08-21 22:36:13 +0300 |
|---|---|---|
| committer | Janne Blomqvist <jb@gcc.gnu.org> | 2018-08-21 22:36:13 +0300 |
| commit | fa3d2d38107033fc7620171474fbb7e2894cc79e (patch) | |
| tree | b106cd8075ae04792a2c458ffd2dbbe9d9711385 /gcc/final.c | |
| parent | 2b4c90656132abb8b8ad155d345c7d4fbf1687c9 (diff) | |
| download | gcc-fa3d2d38107033fc7620171474fbb7e2894cc79e.zip gcc-fa3d2d38107033fc7620171474fbb7e2894cc79e.tar.gz gcc-fa3d2d38107033fc7620171474fbb7e2894cc79e.tar.bz2 | |
Unconditionally use MAX_EXPR/MIN_EXPR for MAX/MIN intrinsics
For floating point types, the question is what MAX(a, NaN) or MIN(a,
NaN) should return (where "a" is a normal number). There are valid
usecases for returning either one, but the Fortran standard doesn't
specify which one should be chosen. Also, there is no consensus among
other tested compilers. In short, it's a mess. So lets just do
whatever is fastest, which is using MAX_EXPR/MIN_EXPR which are not
defined to do anything in particular if one of the operands is a NaN.
gcc/fortran/ChangeLog:
2018-08-21 Janne Blomqvist <jb@gcc.gnu.org>
* trans-intrinsic.c (gfc_conv_intrinsic_minmax): Use
MAX_EXPR/MIN_EXPR unconditionally for real arguments.
* gfortran.texi (Compiler Characteristics): Document MAX/MIN
behavior wrt NaN.
gcc/testsuite/ChangeLog:
2018-08-21 Janne Blomqvist <jb@gcc.gnu.org>
* gfortran.dg/nan_1.f90: Remove tests that test MAX/MIN with NaNs.
From-SVN: r263751
Diffstat (limited to 'gcc/final.c')
0 files changed, 0 insertions, 0 deletions