On Fri, Feb 28, 2020 at 04:32:05PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 28, 2020 at 04:11:15PM +0100, Tobias Burnus wrote:
> > On 2/28/20 3:53 PM, Segher Boessenkool wrote:
> > > It happens with -O2 already. The frontend generates a MIN_EXPR (or
> > > MAX_EXPR) for this, which is undefined for NaNs already. I think the
> > > testcase is just invalid?
> >
> > Ups, that shouldn't happen. It does seem to work here
> > (x86-64-gnu-linux), however, running various compile flags including -O3
> > and -O2.
> >
> > Regarding MIN and MAX: I think the IEEE 754 decided at some point
> > decided that MAX(x, NaN) = x (IEEE 754:2008 alias ISO 60559:2011, if I
> > recall correctly). I think one has to check what exactly the test case
> > does and what is guaranteed where. I also do not know whether a more
> > recent IEEE 754 (754:2019) has changed something again.
>
> Yes, that is what IEEE 754 says I believe.
Yup.
> But that is not what is provided by GCC {MIN,MAX}_EXPR or s{min,max}*
> optabs.
On the other hand, the gfortran manual says
The Fortran standard does not specify what the result of the 'MAX' and
'MIN' intrinsics are if one of the arguments is a 'NaN'. Accordingly,
the GNU Fortran compiler does not specify that either, as this allows
for faster and more compact code to be generated. If the programmer
wishes to take some specific action in case one of the arguments is a
'NaN', it is necessary to explicitly test the arguments before calling
'MAX' or 'MIN', e.g. with the 'IEEE_IS_NAN' function from the intrinsic
module 'IEEE_ARITHMETIC'.
There is IEEE_MAX_NUM, maybe the testcase should use that?
Segher
