https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113570
--- Comment #2 from Robin Dapp <rdapp at gcc dot gnu.org> ---
I'm pretty certain this is "works as intended" and -Ofast causes the precision
to be different than with -O3 (and dependant on the target). See also:
It has been reported that with gfortran -Ofast -march=native verification
errors may be seen, for example:
****************************************
*** Miscompare of pscyee.out; for details see
/data2/johnh/out.v1.1.5/benchspec/CPU/549.fotonik3d_r/run/run_base_refrate_Ofastnative.0000/pscyee.out.mis
0646: -1.91273086037953E-17, -1.46491401919706E-15,
-1.91273086057460E-17, -1.46491401919687E-15,
^
0668: -1.91251317582607E-17, -1.42348205527085E-15,
-1.91251317602571E-17, -1.42348205527068E-15,
^
The errors may occur with other compilers as well, depending on your particular
compiler version, hardware platform, and optimization options.
The problem arises when a compiler chooses to vectorize a particular loop from
power.F90 line number 369
369 do ifreq = 1, tmppower%nofreq
370 frequency(ifreq,ipower) = freq
371 freq = freq + freqstep
372 end do
from https://www.spec.org/cpu2017/Docs/benchmarks/549.fotonik3d_r.html
which further states:
Workaround: You will need to specify optimization options that do not cause
this loop to be vectorized. For example, on a particular platform studied in
mid-2020 using GCC 10.2, these results were seen:
OK -Ofast -march=native -fno-unsafe-math-optimization
If you apply one of the above workarounds in base, be sure to obey the
same-for-all rule which requires that all benchmarks in a suite of a given
language must use the same flags. For example, the sections below turn off
unsafe math optimizations for all Fortran modules in the floating point rate
and floating point speed benchmark suites:
default=base:
OPTIMIZE = -Ofast -flto -march=native
fprate,fpspeed=base:
FOPTIMIZE = -fno-unsafe-math-optimizations
