This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [gfortran,patch] Make MIN and MAX handle NaNs correctly (PR32048)
- From: Tim Prince <tprince at myrealbox dot com>
- To: FX Coudert <fxcoudert at gmail dot com>
- Cc: gfortran list <fortran at gcc dot gnu dot org>, gcc-patches list <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 28 Jul 2007 11:26:11 -0700
- Subject: Re: [gfortran,patch] Make MIN and MAX handle NaNs correctly (PR32048)
- References: <B02CF9DC-25CF-43EE-B361-2B7C60789833@gmail.com>
- Reply-to: tprince at computer dot org
FX Coudert wrote:
Attached patch makes MIN and MAX intrinsics return correct IEEE
results (and consistent results) when given one or more NaN as
arguments. It does so by changing the code generated from MAX(a,b) :=
(b > a ? b : a) into MAX(a,b) := (b > a || isnan(a) ? b : a); handling
of multiple arguments is done similarly.
The introduction of isnan() tests probably has a cost, but hey, we
want a correct result anyway, don't we? Thus, I added a note into the
code saying that when IEEE_ARITHMETIC is implemented, we might want to
make this codepath dependent on IEEE_ARITHMETIC being used (I don't
think we should do that, but we should certainly discuss the option).
Does this affect minval() and maxval() intrinsics? Up to now, they
performed as well as equivalent C code with icpc, better than g++, but
not as well as ifort. I suppose it removes the prospect of vectorizing
code with min() and max(), unless that will be enabled with -ffast-math.