1/inf =? ifort says NaN

[Zaikun]

[See Fortran Discourse for discussions.]

Here is an example that ifort (sometimes) evaluates 1/inf to NaN. I thought it should always be zero. 

Code:

! test.f90
program test
use, intrinsic :: ieee_arithmetic, only : ieee_value, ieee_positive_inf, ieee_support_inf

implicit none

real :: a(5)
real :: b

a = 1.0
b = ieee_value(b, ieee_positive_inf)

write (*, *) 'IEEE_SUPPORT_INF = ', ieee_support_inf(a)
write (*, *) 'A = ', a
write (*, *) 'B = ', b
write (*, *) 'A / B = ', a / b

end program test

Result:

$ uname -a && ifort --version && ifort test.f90 && ./a.out

Linux 5.15.0-52-generic #58-Ubuntu SMP Thu Oct 13 08:03:55 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

ifort (IFORT) 2021.7.1 20221019
Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

 IEEE_SUPPORT_INF =  T
 A =    1.000000       1.000000       1.000000       1.000000       1.000000
 B =	Infinity
 A / B =	NaN	NaN	NaN	NaN	0.0000000E+00                                                                  

See my experiment with Compiler Explorer 2. Strangely, I cannot reproduce the results above without specifying the -O option. On my computer, no option was needed.

1. What do you think is going on here? According to discussions on Fortran Discourse, we understand why the fifth entry of A/B differs from others, but why are the first four NaN?

2. Do Fortran standards specify what 1/inf should be, or are compilers free to (un)define it?

3. From your point of view, is this (default) behavior acceptable / reasonable? What would be your choice if you were going to make a compiler?

Am I the only one surprised by 1/inf = NaN?

Thanks.

[Zaikun]

Can anyone possibly provide a hint about the performance benefit of evaluating `1/Inf` to `NaN` rather than the more reasonable (IMHO) `0`?

If it is beneficial, why doesn't `ifort` evaluate all `1/inf` to `NaN` but leave one of them as `0` in my example? What is the benefit in doing so?

Thank you very much.

[Steve_Lionel]

I'm puzzled that you omitted mention of my reply at the Discourse site that ifort requires you to use -fp-model=strict to get the behavior you want. Comparing the instruction sequences between compiling with and without the strict option, I see they are different. I'm not an expert on the various instructions used, but clearly the optimizer thought performance would be better with the non-strict choice. Because it is using vector instuctions that operate in groups of four, it's not surprising that one out of five is a bit different.