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 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