Hi Richard, Good spot! -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. With pr37336 patch applied: Date & Time : 9 Mar 2023 11:33:31 Test Name : gfor_13 Compile Command : gfc13 -ffast-math -funroll-loops -O2 %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 51720 7.78 2 0.0000 aermod 0.00 1079416 10.35 2 0.1642 air 0.00 87096 3.66 2 0.1230 capacita 0.00 65936 22.88 2 0.0153 channel2 0.00 39832 92.17 2 0.4410 doduc 0.00 182104 14.55 2 0.2509 gas_dyn2 0.00 91784 182.65 2 0.8576 fatigue2 0.00 86496 95.72 2 0.7182 induct2 0.00 183824 100.85 2 0.0084 linpk 0.00 43576 6.19 2 0.4442 mp_prop_desi 0.00 48376 94.72 2 0.4276 nf 0.00 52192 9.84 2 0.1321 protein 0.00 128248 22.06 2 0.0476 rnflow 0.00 136296 25.99 2 0.0462 test_fpu2 0.00 106232 82.97 2 0.0042 tfft2 0.00 35608 47.94 2 0.7071 Geometric Mean Execution Time = 28.68 seconds I think that the PR can be closed. Cheers Paul On Thu, 9 Mar 2023 at 08:18, Richard Biener wrote: > On Wed, 8 Mar 2023, Thomas Koenig wrote: > > > On 08.03.23 15:55, Paul Richard Thomas via Fortran wrote: > > > As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but > > > runs successfully at -O2. > > > > I can confirm that. > > > > > I presume that this is a serious regression since it involves > optimization? > > > Which component should I post it against? > > > > Probably against tree-optimization. If later analysis determines that > > it is something else, people will reassign it. > > > > This one probably calls for bisection. > > I have the following local change to rnflow with that I can't reproduce: > > --- rnflow.f90.orig 2016-06-01 14:50:16.922376347 +0200 > +++ rnflow.f90 2016-06-01 14:56:54.739045162 +0200 > @@ -884,6 +884,7 @@ > ! generation maison d'une valeur pseudo-aleatoire uniforme sur (0,1) > ! > integer, intent (inout) :: jsee ! germe courant > + integer(kind=8) :: jsee_long > integer, parameter :: jmul = 843314861 ! multiplicateur > integer, parameter :: jadd = 453816693 ! constante additive > integer, parameter :: j230 = 1073741824 ! 2 puissance 30 > @@ -899,7 +900,9 @@ > !CRAY - The following multiply must be done with 64 bits (not 46 bits) > ! The algoritm depends on the overflow characteristics of > ! a 32 or 64 bit multiply. > - jsee = jsee * jmul + jadd > + jsee_long = jsee; > + jsee_long = jsee_long * jmul + jadd > + jsee = jsee_long; > !CRAY - Change to avoid 32 bit integer dependency > ! > ! The original line is needlessly dependent on the > > the existing comment already explains the issue. I suppose > -fdefault-integer-8 would also work around the issue? > > ISTR there is an old (closed invalid) bugreport about this as well. > > Richard. > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein