Hi Thomas,
Before answering that, I thought that I had better try the polyhedron suite
with -fwrapv and -std=legacy together. As far as I can see, all is well and
so, yes, I think that is a good idea.
Cheers
Paul
================================================================================
Date & Time : 9 Mar 2023 18:13:04
Test Name : gfor_13
Compile Command : gfc13 -ffast-math -funroll-loops -O3 -fwrapv -std=legacy
%n.f90 -o %n
Benchmarks : ac aermod air capacita channel2 doduc gas_dyn2 fatigue2
induct2 linpk mp_prop_design nf protein rnflow test_fpu2 tfft2
Maximum Times : 10000.0
Target Error % : 0.100
Minimum Repeats : 1
Maximum Repeats : 2
Benchmark Compile Executable Ave Run Number Estim
Name (secs) (bytes) (secs) Repeats Err %
--------- ------- ---------- ------- ------- ------
ac 0.00 55904 7.17 2 0.0628
aermod 0.00 1280104 10.77 2 1.2769
air 0.00 136392 4.09 2 0.4276
capacita 0.00 102680 23.79 2 0.7587
channel2 0.00 43928 108.59 2 0.5834
doduc 0.00 194224 13.98 2 0.2468
gas_dyn2 0.00 104080 105.46 2 0.1659
fatigue2 0.00 90752 62.86 2 1.3092
induct2 0.00 224920 58.08 2 0.6594
linpk 0.00 51768 7.15 2 0.4892
mp_prop_desi 0.00 48432 94.28 2 0.0164
nf 0.00 64480 11.16 2 0.0134
protein 0.00 140592 24.22 2 10.0347
rnflow 0.00 197704 20.74 2 0.1904
test_fpu2 0.00 147232 53.54 2 0.1093
tfft2 0.00 43896 55.09 2 3.8688
Geometric Mean Execution Time = 26.19 seconds
================================================================================
On Thu, 9 Mar 2023 at 17:30, Thomas Koenig <[email protected]> wrote:
> Hi Paul,
>
>
> > -fdefault-integer-8 does indeed fix the problem with
> > rnflow.f90 but breaks tfft2.f90, with a type mismatch at lines 36 and 44.
> >
> > integer(8), parameter :: jmul = 843314861 ! multiplicateur
> > integer(8), parameter :: jadd = 453816693 ! constante additive
> > Does the job and is portable.
> >
>
> I think -frwapv (as suggested by Jakub) would be the better choice.
> The problem is the linear congruential pseudo-random number generators
> which were much used in earlier times (and are still present in
> legacy code), which violate the Fortran standards by assuming silent
> truncation.
>
> If a new optimization breaks this (widespread, but illegal) idiom,
> maybe the best way to deal with it is to add -frwapv to -std=legacy.
>
> What do you think?
>
> Best regards
>
> Thomas
>
--
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
