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 <[email protected]> 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
