[See Fortran Discourse for discussions.]
Here is an example that ifort (sometimes) evaluates 1/inf to NaN. I thought it should always be zero.
! 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
$ 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.
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?
Do Fortran standards specify what 1/inf should be, or are compilers free to (un)define it?
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?
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.
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.