Re: maxval on -inf and nan in Fortran

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: maxval on -inf and nan in Fortran

Tobias Burnus-3
Hi,

(Do you really need to post to gcc@, fortran@ and gcc-patches@?
Shouldn't be one of the list sufficient – like fortran@?)

On 2/28/20 6:02 AM, Jiufu Guo wrote:

> When I check a PR93709, I find the testcase maxlocval_4.f90  […]
> With -ffast-math -O3, this case `STOP 3` on a few platforms, e.g. ppc64le/x86.
To my knowledge, this test case is never be run with -ffast-math;
for sure, it is not run with that option on my x86-64-gnu-linux system.
Given that it uses NaN and INF, it is also not suitable for -ffast-math
(cf. below) – and probably no one has tested or intended to run it with
-ffast-math.

Thus, it is not that unexpected that it fails with -ffast-math. As it
does what it is supposed to do with -O3 and no -ffast-math.

Hence, I fail to understand the problem.

> The test case does not check NaN explicitly.  So, strictly speaking,
> this code may need more stronger to check NaN, otherwise it may STOP
> during execution, and this STOP is acceptable. Right?

In terms of GCC,  "-ffast-math: Sets the options -fno-math-errno,
-funsafe-math-optimizations, -ffinite-math-only, -fno-rounding-math,
-fno-signaling-nans, -fcx-limited-range and -fexcess-precision=fast"
See "man gcc" or https://gcc.gnu.org/onlinedocs/ → GCC Manual
→ "Option Index" or Invoking → Optimization

And in the test case, the neither "mnan" nor "minf" falls under
"finite-math-only".

Regarding -fast-math etc, see also:
https://gcc.gnu.org/wiki/FloatingPointMath
https://gcc.gnu.org/wiki/x87note
https://gcc.gnu.org/wiki/Math_Optimization_Flags

and, talking about FP math in general,
the Goldberg paper, http://www.validlab.com/goldberg/paper.pdf
and similar but both less famous and written more recently:
a paper by Monniaux, https://hal.archives-ouvertes.fr/hal-00128124

Cheers,

Tobias

PS: Using -ffast-math is fine, if one is careful – but one should
then strongly avoid trickery with NaN, INF etc. BTW: Talking about
optimizations, -Ofast (which was not used by you) also enables
-ffast-math but additionally turns implies "-fno-protect-parens",
which otherwise are protected according to the Fortran standard.

-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
Reply | Threaded
Open this post in threaded view
|

Re: maxval on -inf and nan in Fortran

Jakub Jelinek
On Fri, Feb 28, 2020 at 08:53:11AM -0600, Segher Boessenkool wrote:

> On Thu, Feb 27, 2020 at 09:25:27PM -0800, Steve Kargl wrote:
> > On Fri, Feb 28, 2020 at 01:02:28PM +0800, Jiufu Guo wrote:
> > >
> > > With -ffast-math -O3, this case `STOP 3` on a few platforms, e.g. ppc64le/x86.
> >
> > IMHO, using -ffast-math with Fortran code is never correct.
> > With this option, you got exactly what you wanted.
>
> 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?

Or maybe just the FE shouldn't use MIN_EXPR/MAX_EXPR if NaN is allowed,
but fmax/fmaxf/fmaxl etc. or x < y ? x : y or whatever exactly is expected
instead to yield the right answer for NaN?

        Jakub

Reply | Threaded
Open this post in threaded view
|

Re: maxval on -inf and nan in Fortran

Tobias Burnus-3
In reply to this post by Tobias Burnus-3
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.

The Fortran standard by itself does not know about NaN; however, things
do change if an intrinsic IEEE_* module is loaded – I don't quickly
which one needs to be loaded and which part has to be checked there.

I think in terms of NaN/INF and MAX/MIN, the normal MAX/MIN remain the
same (nothing said about nonnormal numbers except 0), but IEEE_MAX_NUM
does take care of the IEEE 754 semantic.

Tobias

PS: I currently do not have the time dig into this; maybe on Monday or
at the weekend.

-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
Reply | Threaded
Open this post in threaded view
|

Re: maxval on -inf and nan in Fortran

Segher Boessenkool
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