Re: maxval on -inf and nan in Fortran
Joseph Myers writes: > On Fri, 28 Feb 2020, Tobias Burnus wrote: > >> 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. > > It has. The maxNum/minNum operations from IEEE 754-2008 were removed and > replaced by recommended operations maximum/minimum (treat NaNs the same > way as other operations do, i.e. produce a quiet NaN result if either > operand is a NaN) and maximumNumber/minimumNumber (return the number if > the other operand is a NaN, even a signaling NaN, with "invalid" raised in > the signaling NaN case). Those new operations also treat +0 as greater > than -0, whereas maxNum/minNum did not specify the result in that case. > (The choice of which operand is the result is still unspecified when the > two operands are different DFP members of the same cohort, i.e. with > different quantum exponents.) Hi, Thanks for all your great comments! IEEE 754 also updates the behavior of min/max on NaN, and seems try to meet difference purpose with special operations. So, I feel GNU Fortran manual is still a good decision as: https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gfortran/MAX-and-MIN-intrinsics-with-REAL-NaN-arguments.html#MAX-and-MIN-intrinsics-with-REAL-NaN-arguments It is undefined to use max/min on NaN without check IS_NAN or without using specified IEEE operations. Jiufu
Re: maxval on -inf and nan in Fortran
On Fri, 28 Feb 2020, Tobias Burnus wrote: > 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. It has. The maxNum/minNum operations from IEEE 754-2008 were removed and replaced by recommended operations maximum/minimum (treat NaNs the same way as other operations do, i.e. produce a quiet NaN result if either operand is a NaN) and maximumNumber/minimumNumber (return the number if the other operand is a NaN, even a signaling NaN, with "invalid" raised in the signaling NaN case). Those new operations also treat +0 as greater than -0, whereas maxNum/minNum did not specify the result in that case. (The choice of which operand is the result is still unspecified when the two operands are different DFP members of the same cohort, i.e. with different quantum exponents.) -- Joseph S. Myers jos...@codesourcery.com
Re: maxval on -inf and nan in Fortran
On Fri, Feb 28, 2020 at 06:50:20PM +0100, Thomas Koenig wrote: > Am 28.02.20 um 17:58 schrieb Steve Kargl: > > Replacing MIN_EXPR/MAX_EXPR (everywhere?) would seem to > > be a pessimization for correctly written code. > > Also note the following part of changes.html for 9.2: > > The MAX and MIN intrinsics are no longer guaranteed to return any > particular value in case one of the arguments is a NaN. Note that this > conforms to the Fortran standard and to what other Fortran compilers do. > If there is a need to handle that case in some specific way, one needs > to explicitly check for NaN's before calling MAX or MIN, e.g. by using > the IEEE_IS_NAN function from the intrinsic module IEEE_ARITHMETIC. > > This was discussed (and decided) at the time. But then the tests shouldn't actually test it, or should be restricted to targets where it will work anyway at least. Jakub
Re: maxval on -inf and nan in Fortran
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
Re: maxval on -inf and nan in Fortran
Am 28.02.20 um 17:58 schrieb Steve Kargl: Replacing MIN_EXPR/MAX_EXPR (everywhere?) would seem to be a pessimization for correctly written code. Also note the following part of changes.html for 9.2: The MAX and MIN intrinsics are no longer guaranteed to return any particular value in case one of the arguments is a NaN. Note that this conforms to the Fortran standard and to what other Fortran compilers do. If there is a need to handle that case in some specific way, one needs to explicitly check for NaN's before calling MAX or MIN, e.g. by using the IEEE_IS_NAN function from the intrinsic module IEEE_ARITHMETIC. This was discussed (and decided) at the time. Regards Thomas
Re: maxval on -inf and nan in Fortran
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. IEEE-754-2008 does not have MAX(), and it defines quiet and signaling NaNs. It does have maxNum(): maxNum(x, y) is the canonicalized number y if x < y, x if y < x, the canonicalized number if one operand is a number and the other a quiet NaN. Otherwise it is either x or y, canonicalized (this means results might differ among implementations). When either x or y is a signalingNaN, then the result is according to 6.2. -- Steve
Re: maxval on -inf and nan in Fortran
On Fri, Feb 28, 2020 at 04:04:10PM +0100, Jakub Jelinek wrote: > 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? > If a Fortran program does not use the IEEE_ARITHMETIC module and specifically handle +-inf and nan and that program generates one of those values, then that program is in "undefined behavior" territory. Replacing MIN_EXPR/MAX_EXPR (everywhere?) would seem to be a pessimization for correctly written code. -- Steve
Re: maxval on -inf and nan in Fortran
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.
But that is not what is provided by GCC {MIN,MAX}_EXPR or s{min,max}*
optabs.
See https://gcc.gnu.org/ml/gcc-patches/2005-01/msg01609.html that documented
it.
So, in short, the FE shouldn't emit {MIN,MAX}_EXPR if it expects the IEEE
754 behavior and should instead emit something different, like
COND_EXPR.
If one writes in C:
double foo (double x, double y) { return x > y ? x : y; }
double bar (double x, double y) { return x >= y ? x : y; }
it is also only converted into MAX_EXPR if one uses -ffinite-math-only
-fno-signed-zeros and not otherwise. Already fold-const.c can do that,
or e.g. phiopt pass.
Jakub
Re: maxval on -inf and nan in Fortran
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
Re: maxval on -inf and nan in Fortran
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
Re: maxval on -inf and nan in Fortran
Hi Tobias, On Fri, Feb 28, 2020 at 10:58:36AM +0100, Tobias Burnus wrote: > (Do you really need to post to gcc@, fortran@ and gcc-patches@? > Shouldn't be one of the list sufficient – like fortran@?) Many people do not read that list. I asked Jiu Fu to post to both fortran@ and one of gcc@ and gcc-patches@, but I wasn't clear enough I guess. Sorry :-) https://gcc.gnu.org/lists.html says fortran is the main discussion and development list for the Fortran language front end of GCC, and the corresponding runtime library. Patches to gfortran and libgfortran should go to both this list and gcc-patches. Segher
Re: maxval on -inf and nan in Fortran
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? Segher
Re: maxval on -inf and nan in Fortran
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
Re: maxval on -inf and nan in Fortran
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. -- Steve
