Re: [Patch, fortran] PR37336 finalization

[Thomas Koenig via Fortran]

Hi Paul,


I want to get something approaching correct finalization to the
distros, which implies 12-branch at present. Hopefully I can do the
same with associate in a month or two's time.


OK by me then.

(I just wanted to be sure that we had this discussion :-)

Best regards

Thomas

Re: [Patch, fortran] PR37336 finalization

[Harald Anlauf via Fortran]

Hi Paul, all,

On 6/3/23 15:16, Paul Richard Thomas via Gcc-patches wrote:

Hi Thomas,

I want to get something approaching correct finalization to the
distros, which implies 12-branch at present. Hopefully I can do the
same with associate in a month or two's time.


IMHO it is not only distros, but also installations at (scientific)
computing centers with a larger user base and a large software stack.
Migrating to a different major version of gcc/gfortran is not a trivial
task for them.

I'd fully support the idea of backporting the finalization fixes, as
IIUC this on the one hand touches a rather isolated part, and on the
other hand already got quite some testing.  It is also already in the
13-branch (or only mostly?).  Given that 12.3 was released recently
and 12.4 is far away, there'd be sufficient time to fix any fallout.

Regarding the associate fixes, we could get as much of those into 13.2,
which we'd normally expect in just a few months.  As long as spare time
to work on gfortran is limited, I'd rather prefer to get as much fixed
for that release.

(This is not a no: I simply expect that real regression testing for the
associate changes may take more time.)


I am dithering about changing the F2003/08 part of finalization since
the default is 2018 compliance. That said, it does need a change since
the suppression of constructor finalization is also suppressing
finalization of function results within the compilers. I'll do that
first, perhaps?


That sounds like a good idea.

Cheers,
Harald


Cheers

Paul



On Sat, 3 Jun 2023 at 06:50, Thomas Koenig  wrote:


Hi Paul,


I propose to backport
r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very
soon.


Is this something that we usually do?

While finalization was basically broken before, some people still used
working subsets (or subsets that were broken, and they adapted or
wrote their code accordingly).

What is the general opinion on that?  I'm undecided.


Before that, I propose to remove the F2003/2008 finalization of
structure and array constructors in 13- and 14-branches. I can see why
it was removed from the standard in a correction to F2008 and think
that it is likely to cause endless confusion and maintenance
complications. However, finalization of function results within
constructors will be retained.


That, I agree with.  Should it be noted somewhere as an intentional
deviation from the standard?

Best regards

 Thomas




--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: [Patch, fortran] PR37336 finalization

[Paul Richard Thomas via Fortran]

Hi Thomas,

I want to get something approaching correct finalization to the
distros, which implies 12-branch at present. Hopefully I can do the
same with associate in a month or two's time.

I am dithering about changing the F2003/08 part of finalization since
the default is 2018 compliance. That said, it does need a change since
the suppression of constructor finalization is also suppressing
finalization of function results within the compilers. I'll do that
first, perhaps?

Cheers

Paul



On Sat, 3 Jun 2023 at 06:50, Thomas Koenig  wrote:
>
> Hi Paul,
>
> > I propose to backport
> > r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very
> > soon.
>
> Is this something that we usually do?
>
> While finalization was basically broken before, some people still used
> working subsets (or subsets that were broken, and they adapted or
> wrote their code accordingly).
>
> What is the general opinion on that?  I'm undecided.
>
> > Before that, I propose to remove the F2003/2008 finalization of
> > structure and array constructors in 13- and 14-branches. I can see why
> > it was removed from the standard in a correction to F2008 and think
> > that it is likely to cause endless confusion and maintenance
> > complications. However, finalization of function results within
> > constructors will be retained.
>
> That, I agree with.  Should it be noted somewhere as an intentional
> deviation from the standard?
>
> Best regards
>
> Thomas
>


--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: [Patch, fortran] PR37336 finalization

[Steve Kargl via Fortran]

On Sat, Jun 03, 2023 at 07:50:19AM +0200, Thomas Koenig via Fortran wrote:
> Hi Paul,
> 
> > I propose to backport
> > r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very
> > soon.
> 
> Is this something that we usually do?
> 
> While finalization was basically broken before, some people still used
> working subsets (or subsets that were broken, and they adapted or
> wrote their code accordingly).
> 
> What is the general opinion on that?  I'm undecided.
> 

I think a backport that fixes a bug that is a violation
of Fortran standard is always okay.  A backport of anything
else is up to the discretion of the contributor.  If pault
or you or harald or ... want to backport a patch, after all
these years, I think we should trust their judgement.

-- 
Steve

Re: [Patch, fortran] PR37336 finalization

[Thomas Koenig via Fortran]

Hi Paul,


I propose to backport
r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very
soon.


Is this something that we usually do?

While finalization was basically broken before, some people still used
working subsets (or subsets that were broken, and they adapted or
wrote their code accordingly).

What is the general opinion on that?  I'm undecided.


Before that, I propose to remove the F2003/2008 finalization of
structure and array constructors in 13- and 14-branches. I can see why
it was removed from the standard in a correction to F2008 and think
that it is likely to cause endless confusion and maintenance
complications. However, finalization of function results within
constructors will be retained.


That, I agree with.  Should it be noted somewhere as an intentional
deviation from the standard?

Best regards

Thomas

Re: [Patch, fortran] PR37336 finalization

[Paul Richard Thomas via Fortran]

Hi All,

I propose to backport
r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very
soon. Before that, I propose to remove the F2003/2008 finalization of
structure and array constructors in 13- and 14-branches. I can see why
it was removed from the standard in a correction to F2008 and think
that it is likely to cause endless confusion and maintenance
complications. However, finalization of function results within
constructors will be retained.

If there are any objections, please let me know.

Paul

Re: [Patch, fortran] PR37336 finalization

[Paul Richard Thomas via Fortran]

Thank you, Richard.

I am planning to commit either very late tonight, Friday night or early on
Saturday morning to avoid any interference by other commits. It will take
me a little while to get it done and so I want to reduce the probability of
a mid-air collision.

Best regards

Paul

>

Re: [Patch, fortran] PR37336 finalization

[Richard Biener via Fortran]

On Wed, 15 Mar 2023, Paul Richard Thomas wrote:

> Hi All,
> 
> I am awaiting a green light to commit this patch or not.

I'd say go ahead.

Richard.

> Cheers
> 
> Paul
> 
> 
> On Fri, 10 Mar 2023 at 16:49, Paul Richard Thomas <
> paul.richard.tho...@gmail.com> wrote:
> 
> > 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   :1.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   43928108.59   2  0.5834
> >doduc  0.00  194224 13.98   2  0.2468
> > gas_dyn2  0.00  104080105.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
> >
> 
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)

Re: [Patch, fortran] PR37336 finalization

[Paul Richard Thomas via Fortran]

Hi All,

I am awaiting a green light to commit this patch or not.

Cheers

Paul


On Fri, 10 Mar 2023 at 16:49, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:

> 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   :1.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   43928108.59   2  0.5834
>doduc  0.00  194224 13.98   2  0.2468
> gas_dyn2  0.00  104080105.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
>


-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

Re: [Patch, fortran] PR37336 finalization

[Paul Richard Thomas via Fortran]

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   :1.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   43928108.59   2  0.5834
   doduc  0.00  194224 13.98   2  0.2468
gas_dyn2  0.00  104080105.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

Re: [Patch, fortran] PR37336 finalization

[Jerry D via Fortran]

While recovering from an illness here folks I have been following all of 
these discussions.  I think I will put in my two cents worth.


From what i can see, Paul's patch breaks nothing and fixes many things. 
 The only thing holding us back is fear we might break something. The 
likelihood of actually breaking something is very low. The consequences 
of breaking anything, worst case, is to revert a patch. (ie no consequence)


It is clear to me the value added clearly exceeds the the risks by a 
lot. Therefore, as Spock would say, it is illogical to not make a 
decision and move forward with this finalization patch, and commit it. 
More will be advanced from making this decision from not making this 
decision.


Regards,

Jerry

On 3/9/23 9:30 AM, Thomas Koenig via Fortran 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

Re: [Patch, fortran] PR37336 finalization

[Thomas Koenig via Fortran]

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

Re: [Patch, fortran] PR37336 finalization

[Steve Kargl via Fortran]

On Thu, Mar 09, 2023 at 08:18:08AM +, Richard Biener wrote:
>
> the existing comment already explains the issue.  I suppose
> -fdefault-integer-8 would also work around the issue?
> 

Please, no.  -fdefault-* options should have been removed
from gfortran years ago.  Without a careful review, one 
might be stepping into a minefield, because the -fdefault-*
option break storage association rules.  If you want to use
an option, then you likely want -finteger-4-integer-8.  This
option preserves storage association.

-- 
Steve

Re: [Patch, fortran] PR37336 finalization

[Paul Richard Thomas via Fortran]

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   :1.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.
  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   91784182.65   2  0.8576
fatigue2  0.00   86496 95.72   2  0.7182
 induct2  0.00  183824100.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

Re: [Patch, fortran] PR37336 finalization

[Richard Biener via Fortran]

On Thu, 9 Mar 2023, Thomas Koenig wrote:

> On 08.03.23 22:35, I 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 submitted this as
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 .
> 
> Paul, thanks for catching this!
> 
> @Richard: Is there a possibility of doing regular Polyhedron runs
> at Suse in addition to the SPEC runs?  This could also be interesting.

We do run Polyhedron on a variety of machines already, you can visit
https://lnt.opensuse.org/db_default/v4/CPP/latest_runs_report
which is the benchmark set that includes polyhedron.

Richard.

Re: [Patch, fortran] PR37336 finalization

[Richard Biener via Fortran]

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.

Re: [Patch, fortran] PR37336 finalization

[Thomas Koenig via Fortran]

On 08.03.23 22:35, I 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 submitted this as

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 .

Paul, thanks for catching this!

@Richard: Is there a possibility of doing regular Polyhedron runs
at Suse in addition to the SPEC runs?  This could also be interesting.

Best regards

Thomas

Re: [Patch, fortran] PR37336 finalization

[Thomas Koenig via Fortran]

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.

Regards

Thomas

Re: [Patch, fortran] PR37336 finalization

[Paul Richard Thomas via Fortran]

Hi Tobias,

I agree completely with all that you are saying. Declaring derived types in
a module is guaranteed to produce vtables and final wrappers, so that they
are available in scopes where they are used. Had we thought more about
class design, we might have added the vtable to the entity, rather than
using a pointer to it. Anyway, the pointer does act as a useful
identification for the type. As an example:
module m
  type t
integer :: i
  end type
  type s
type(t), allocatable :: j
  end type
end module
  use m
  call foo
contains
  subroutine foo
type(s), allocatable :: a
a = s(t(42))
print *, a%j
  end subroutine
end
 generates a final wrapper '__final_m_S', although it is not called on
leaving 'foo' scope because there are no final procedures.

Just to confirm what I said earlier: The unpatched and patched mainlines
both complete the polyhedron tests, including rnflow.f90, with -O2.

Date & Time :  8 Mar 2023 14:45:29
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   :1.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.0386
  aermod  0.00 1079416 10.32   2  0.1599
 air  0.00   87096  3.59   2  0.4316
capacita  0.00   65936 22.81   2  0.1951
channel2  0.00   39832104.15   2  0.7287
   doduc  0.00  182104 14.40   2  0.0035
gas_dyn2  0.00   91784181.61   2  0.1261
fatigue2  0.00   86496 95.34   2  0.2061
 induct2  0.00  183824101.46   2  0.3992
   linpk  0.00   43576  6.16   2  0.4545
mp_prop_desi  0.00   48376 94.77   2  0.2168
  nf  0.00   52192  9.94   2  0.2363
 protein  0.00  128248 22.73   2  1.4098
  rnflow  0.00  136296 26.17   2  0.1051
   test_fpu2  0.00  106232 83.34   2  0.0360
   tfft2  0.00   35608 46.70   2  0.5439

Geometric Mean Execution Time =  28.87 seconds

Paul

Re: [Patch, fortran] PR37336 finalization

[Tobias Burnus]

On 08.03.23 16:12, Steve Kargl via Fortran wrote:

For one of my codes, I see
% foreach i (*.o)
foreach? nm $i | grep final
foreach? end
0280 T __beamsm_MOD___final_beamsm_Table_t
0580 T __bsam_MOD___final_bsam_Bsa_info_t
01e0 T __bsam_MOD___final_bsam_Bsa_t
00a0 T __ffn_data_MOD___final_ffn_data_Fe_t

I do not explicitly use finalization nor do I have
subprograms named __final_*.  To me, this re-inforces
Richard's point about not breaking existing code.


I think there are two places where finalization is touched: (a) when
declaring a type, finalization procedures might get generated.(*) — And,
(b) invoking finalization procedures.

(a) happens if you have you explicitly add finalization functions – or
(I believe) when you have allocatable components as GCC may then need to
free them.

I think (b) only happens if you either have polymorphism (as then you
don't know whether the polymorphic function uses finalization) – or when
you invoke explicitly finalization.

I believe you run into (a) – the finalization generation. My
understanding is that Paul's patch is mostly about (b) and for sure not
for the default-generated procedures. But of course, any code one
touches for one purpose can still have side effects, affecting seemingly
unrelated code.

Tobias

PS: I think we should change at some point when the virtual tables and
their default procs (init, copy, finalize) generated.

Namely, instead of generating them for all types – even if not used – it
makes sense to generate them only when a type is used in CLASS(t). This
will lead to the generation in multiple translation units, but weak
symbols come to a rescue – and for a MODULE, it can be stored in the
.mod file that the vtable + funcs has been generated. That way, way
fewer vtables are generated, saving a lot of space and reducing compile
time!

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: [Patch, fortran] PR37336 finalization

[Andrew Benson via Fortran]

I agree with Steve that the lack of finalization support in gfortran means 
there are not many open-source Fortran projects that rely on it.

I've made extensive use of finalization:

https://github.com/galacticusorg/galacticus

An issue with this is that I had to work-around the missing pieces of 
finalization (e.g. finalization of function results). Now that those are 
implemented, my code breaks with Paul's finalization patch applied. This just 
requires me to go through the code and remove those workarounds (which will 
result in much cleaner code - so I'm very happy that finalization is now fully 
implemented).

So, it's possible that any other projects that have used the previous, 
incomplete finalization implementation might similarly break with the new 
patch. So, maybe some explanation of this in the release notes would be 
helpful so that users are made aware of possible problems.

-Andrew

On Wednesday, March 8, 2023 7:12:04 AM PST Steve Kargl via Fortran wrote:
> On Wed, Mar 08, 2023 at 07:32:55AM +, Paul Richard Thomas wrote:
> > Could you please review the patch on that self same time scale? I would be
> > happy to have feedback one file at a time.
> 
> Yes, I'll commit time to review individual patches.  Smaller
> patches are typically easier to review.
> 
> As to other topics in the thread, I suspect you won't
> find a lot of open-source Fortran project that make heavy
> use of finalization.  This is likely due to gfortran's
> current lack of robust support.  There, however, must
> some implicit finalization already occurring.  For one
> of my codes, I see
> 
> % foreach i (*.o)
> foreach? nm $i | grep final
> foreach? end
> 0280 T __beamsm_MOD___final_beamsm_Table_t
> 0580 T __bsam_MOD___final_bsam_Bsa_info_t
> 01e0 T __bsam_MOD___final_bsam_Bsa_t
> 00a0 T __ffn_data_MOD___final_ffn_data_Fe_t
> 
> I do not explicitly use finalization nor do I have
> subprograms named __final_*.  To me, this re-inforces
> Richard's point about not breaking existing code.


-- 

* Andrew Benson: https://abensonca.github.io

* Galacticus: https://github.com/galacticusorg/galacticus

Re: [Patch, fortran] PR37336 finalization

[Steve Kargl via Fortran]

On Wed, Mar 08, 2023 at 07:32:55AM +, Paul Richard Thomas wrote:
> 
> Could you please review the patch on that self same time scale? I would be
> happy to have feedback one file at a time.
> 

Yes, I'll commit time to review individual patches.  Smaller
patches are typically easier to review.

As to other topics in the thread, I suspect you won't
find a lot of open-source Fortran project that make heavy
use of finalization.  This is likely due to gfortran's
current lack of robust support.  There, however, must
some implicit finalization already occurring.  For one
of my codes, I see

% foreach i (*.o)
foreach? nm $i | grep final 
foreach? end
0280 T __beamsm_MOD___final_beamsm_Table_t
0580 T __bsam_MOD___final_bsam_Bsa_info_t
01e0 T __bsam_MOD___final_bsam_Bsa_t
00a0 T __ffn_data_MOD___final_ffn_data_Fe_t

I do not explicitly use finalization nor do I have 
subprograms named __final_*.  To me, this re-inforces
Richard's point about not breaking existing code.

-- 
Steve

Re: [Patch, fortran] PR37336 finalization

[Richard Biener via Fortran]

On Wed, 8 Mar 2023, Paul Richard Thomas wrote:

> Hi All,
> 
> I ran the polyhedron testsuite with the patched gfortran-13.0.1 and 7.4(as
> used in the posted Linux test). The timings are comparable except for
> rnflow.f90.
> 
> As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but
> runs successfully at -O2.
> 
> I presume that this is a serious regression since it involves optimization?

I believe it has undefined behavior (accessing array out of bounds).

> Which component should I post it against?
> 
> Regards
> 
> Paul
> 
> gfortran 13.0.1 with patch
>Benchmark   Compile  Executable   Ave Run  Number   Estim
> Name(secs) (bytes)(secs) Repeats   Err %
>-   ---  --   --- ---  --
>   ac  0.00   55904  7.28   2  0.0550
>   aermod  0.00 1149032 10.32   2  0.0242
>  air  0.00  120224  3.57   2  0.3083
> capacita  0.00  110872 20.27   2  0.0765
> channel2  0.00   43928 98.23   2  0.2703
>doduc  0.00  190296 13.86   2  0.2453
> gas_dyn2  0.00  108176 96.77   2  0.1364
> fatigue2  0.00   90752 61.44   2  0.0618
>  induct2  0.00  224992 57.71   2  0.0572
>linpk  0.00   47672  5.54   2  0.1806
> mp_prop_desi  0.00   52640 94.50   2  0.0079
>   nf  0.00   64480  9.25   2  0.4053
>  protein  0.00  136496 20.83   2  0.9096
>   rnflow  0.00  181320   3417.15   2 99.8270
>test_fpu2  0.00  126752 52.35   2  0.1691
>tfft2  0.00   60280 37.61   2  0.9387
> 
> Geometric Mean Execution Time =  32.72 seconds
> rnflow hangs without patch as well. Seems to be a rather serious
> regression.
> gets stuck with -O3 in the loop starting at line 3566 in subroutine cptrf2
> 
> 
> 
> gfortran7.4
>Benchmark   Compile  Executable   Ave Run  Number   Estim
> Name(secs) (bytes)(secs) Repeats   Err %
>-   ---  --   --- ---  --
>   ac  0.00 3612576  7.30   2  0.0205
>   aermod  0.00 5204760 10.21   2  0.0784
>  air  0.00 3829736  4.05   2  0.0988
> capacita  0.00 3672512 22.25   2  0.1506
> channel2  0.00 3663368 87.22   2  0.5767
>doduc  0.00 3840336 13.60   2  0.0221
> gas_dyn2  0.00 3673920 89.54   2  0.1106
> fatigue2  0.00 3691256 74.34   2  0.0921
>  induct2  0.00 4062312 57.87   2  0.1348
>linpk  0.00 3591984  5.59   2  0.0358
> mp_prop_desi  0.00 3966920 93.99   2  0.0654
>   nf  0.00 3622112  9.27   2  0.0324
>  protein  0.00 3832280 22.10   2  0.1289
>   rnflow  0.00 4129984 23.49   2  0.7449
>test_fpu2  0.00 3940944 53.29   2  0.2561
>tfft2  0.00 3622040 36.56   2  0.1026
> 
> Geometric Mean Execution Time =  24.33 seconds
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)

Re: [Patch, fortran] PR37336 finalization

[Paul Richard Thomas via Fortran]

Hi All,

I ran the polyhedron testsuite with the patched gfortran-13.0.1 and 7.4(as
used in the posted Linux test). The timings are comparable except for
rnflow.f90.

As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but
runs successfully at -O2.

I presume that this is a serious regression since it involves optimization?
Which component should I post it against?

Regards

Paul

gfortran 13.0.1 with patch
   Benchmark   Compile  Executable   Ave Run  Number   Estim
Name(secs) (bytes)(secs) Repeats   Err %
   -   ---  --   --- ---  --
  ac  0.00   55904  7.28   2  0.0550
  aermod  0.00 1149032 10.32   2  0.0242
 air  0.00  120224  3.57   2  0.3083
capacita  0.00  110872 20.27   2  0.0765
channel2  0.00   43928 98.23   2  0.2703
   doduc  0.00  190296 13.86   2  0.2453
gas_dyn2  0.00  108176 96.77   2  0.1364
fatigue2  0.00   90752 61.44   2  0.0618
 induct2  0.00  224992 57.71   2  0.0572
   linpk  0.00   47672  5.54   2  0.1806
mp_prop_desi  0.00   52640 94.50   2  0.0079
  nf  0.00   64480  9.25   2  0.4053
 protein  0.00  136496 20.83   2  0.9096
  rnflow  0.00  181320   3417.15   2 99.8270
   test_fpu2  0.00  126752 52.35   2  0.1691
   tfft2  0.00   60280 37.61   2  0.9387

Geometric Mean Execution Time =  32.72 seconds
rnflow hangs without patch as well. Seems to be a rather serious
regression.
gets stuck with -O3 in the loop starting at line 3566 in subroutine cptrf2



gfortran7.4
   Benchmark   Compile  Executable   Ave Run  Number   Estim
Name(secs) (bytes)(secs) Repeats   Err %
   -   ---  --   --- ---  --
  ac  0.00 3612576  7.30   2  0.0205
  aermod  0.00 5204760 10.21   2  0.0784
 air  0.00 3829736  4.05   2  0.0988
capacita  0.00 3672512 22.25   2  0.1506
channel2  0.00 3663368 87.22   2  0.5767
   doduc  0.00 3840336 13.60   2  0.0221
gas_dyn2  0.00 3673920 89.54   2  0.1106
fatigue2  0.00 3691256 74.34   2  0.0921
 induct2  0.00 4062312 57.87   2  0.1348
   linpk  0.00 3591984  5.59   2  0.0358
mp_prop_desi  0.00 3966920 93.99   2  0.0654
  nf  0.00 3622112  9.27   2  0.0324
 protein  0.00 3832280 22.10   2  0.1289
  rnflow  0.00 4129984 23.49   2  0.7449
   test_fpu2  0.00 3940944 53.29   2  0.2561
   tfft2  0.00 3622040 36.56   2  0.1026

Geometric Mean Execution Time =  24.33 seconds

Re: [Patch, fortran] PR37336 finalization

[Paul Richard Thomas via Fortran]

Hi Richard,

Smart pointer applications really torture finalization. That's why Andrew
and Salvatore's help has been so much appreciated.

I haven't run the polyhedron suite for some little while and so I just
downloaded it. I ran into a significant problem with the harness. The
binary segfaulted before doing anything and the source appeared to be
geared towards Intel but I couldn't get it to compile even with ifort. I
replaced all the offending bits of code with standard calls and put the
tests on to cook. The posted linux tests were done with gcc-7.4 so I will
rerun the suite with that and compare the outcomes. So far I haven't seen
any problems. On the contrary, some invalid code nasties were picked up:
 3586 |  DO ij = 1 , 3
  |  2
 3587 | QUGii(ij) = 0.
 3588 | QCOni(ij) = 0.
  |  1
Warning: Array reference at (1) out of bounds (3 > 2) in loop beginning at
(2)
doduc.f90:3587:26:

 3587 | QUGii(ij) = 0.
  |  ^
Warning: iteration 2 invokes undefined behavior
[-Waggressive-loop-optimizations]
doduc.f90:3586:16:
and
gas_dyn2.f90:435:21:

   59 |   SUBROUTINE KEEL(NODES, DX, RADIUS, RBOUND, VEL, DENS, IENER,
 &
  | 2
..
  435 |   SUBROUTINE KEEL(NODES, DX, RADIUS, RBOUND, VEL, DENS, IENER,
 &
  | 1
Warning: Shape mismatch in dimension 1 of argument 'dx' between (1) and (2)
The IEEE underflow and denormal errors are also flagged.

As soon as the runs are finished, I will post the results.

@Tobias Burnus   Thanks for the pointer to Octopus. I'll
give it a whirl tonight.

Cheers

Paul


On Wed, 8 Mar 2023 at 09:10, Richard Biener  wrote:

> On Wed, 8 Mar 2023, Thomas Koenig wrote:
>
> > On 08.03.23 09:14, Richard Biener wrote:
> > > While Fortran is not considered release critical it would be bad to
> > > break say the build of SPEC CPU 2017 or Polyhedron very late in the
> > > cycle.  I'd lean towards postponing this to early stage1 and eventually
> > > backport it for GCC 13.2 if you would like this feature to be
> implemented
> > > for GCC 13.
> >
> > And now comes the problem - no Fortran maintanier has access to SPEC
> > 2017, as far as I know.  The curse of closed-source benchmarks...
>
> :/
>
> But at least you can watch https://lnt.opensuse.org after-the-fact
>
> > How extensive is SPEC using finalization?  My personal guess would be
> > that it is not used extensively, since gfortran's implementation is
> > pretty broken at the moment.
>
> I'd say it probably doesn't use it.  But I was more worrying about
> unwanted side-effects on code _not_ using finalization.
>
> Do you know of any medium to large size Fortran code base that
> uses finalization?
>
> Richard.
>


-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

Re: [Patch, fortran] PR37336 finalization

[Tobias Burnus]

On 08.03.23 09:55, Thomas Koenig via Fortran wrote:

And now comes the problem - no Fortran maintanier has access to SPEC
2017, as far as I know.  The curse of closed-source benchmarks...


We (as in Codesourcery) have access to the older SPEC Accel and the
newer SPEC HPC (but not to SPEC CPU – which SUSE has access to). In SPEC
HPC, I did not see any 'final ::'.

For code using finalization: In the popular non-free
electronic-structure code VASP (used to calculate molecules), I see a
single 'final::'.

A similar less popular program is Octopus,
https://gitlab.com/octopus-code/octopus That would be a real-world code
that uses 45 times 'final', 80 times 'type, extends(...)' and a thousand
times 'class(...)'. Thus, that could be a real-world testcase. (I have
not built it for a longer time.* It includes a regression-test suite.)

Tobias

(*) Octopus: I haven't build it for a longer time, but I think it should
build without too much trouble. That was the program the group
co-developed where I did my master thesis.  / If you want to see what it
does: https://en.wikipedia.org/wiki/Octopus_(software) or
https://octopus-code.org/

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: [Patch, fortran] PR37336 finalization

[Richard Biener via Fortran]

On Wed, 8 Mar 2023, Paul Richard Thomas wrote:

> The alternative is that the patch be reviewed and committed as it is. I
> have been neglecting my daytime job to get to this point and must spend
> some time catching up.

That works for me as well - I understand the work to be done is on
the testsuite side, so we should get more time to test the actual
code changes on the real world.

Richard.

Re: [Patch, fortran] PR37336 finalization

[Paul Richard Thomas via Fortran]

The alternative is that the patch be reviewed and committed as it is. I
have been neglecting my daytime job to get to this point and must spend
some time catching up.

Cheers

Paul


On Wed, 8 Mar 2023 at 08:05, Thomas Koenig  wrote:

> Hi Paul,
>
> > Last night, I scoped out the work required to get the patch ready to
> > commit. Sorting out the testcases will be the main load since they have
> > grown "organically". I propose to change over to one test for each
> > paragraph of F2018 7.5.6.2/7.5.6.3  and to
> > verify them against the other brands. I suspect that this will allow a
> > weeding out of the existing tests. It will take me a couple of weeks.
>
> I am a little bit concerned that this might bring us too close to the
> release date. We are down to 22 P1 regressions as of now.
>
> Richard, what do you think?
>
> Best regards
>
> Thomas
>
>
>

-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

Re: [Patch, fortran] PR37336 finalization

[Richard Biener via Fortran]

On Wed, 8 Mar 2023, Thomas Koenig wrote:

> On 08.03.23 09:14, Richard Biener wrote:
> > While Fortran is not considered release critical it would be bad to
> > break say the build of SPEC CPU 2017 or Polyhedron very late in the
> > cycle.  I'd lean towards postponing this to early stage1 and eventually
> > backport it for GCC 13.2 if you would like this feature to be implemented
> > for GCC 13.
> 
> And now comes the problem - no Fortran maintanier has access to SPEC
> 2017, as far as I know.  The curse of closed-source benchmarks...

:/

But at least you can watch https://lnt.opensuse.org after-the-fact

> How extensive is SPEC using finalization?  My personal guess would be
> that it is not used extensively, since gfortran's implementation is
> pretty broken at the moment.

I'd say it probably doesn't use it.  But I was more worrying about
unwanted side-effects on code _not_ using finalization.

Do you know of any medium to large size Fortran code base that
uses finalization?

Richard.

Re: [Patch, fortran] PR37336 finalization

[Thomas Koenig via Fortran]

On 08.03.23 09:14, Richard Biener wrote:

While Fortran is not considered release critical it would be bad to
break say the build of SPEC CPU 2017 or Polyhedron very late in the
cycle.  I'd lean towards postponing this to early stage1 and eventually
backport it for GCC 13.2 if you would like this feature to be implemented
for GCC 13.


And now comes the problem - no Fortran maintanier has access to SPEC
2017, as far as I know.  The curse of closed-source benchmarks...

How extensive is SPEC using finalization?  My personal guess would be
that it is not used extensively, since gfortran's implementation is
pretty broken at the moment.

Polyhedron we can test, of course, but a grep of the sources shows
that finalization is not used there at all.


But it's of course the Fortran maintainers decision.

Even though Fortran isn't release critical we might ask you to revert
if any such severe problems show up.


Sure.

Best regards

Thomas

Re: [Patch, fortran] PR37336 finalization

[Richard Biener via Fortran]

On Wed, 8 Mar 2023, Thomas Koenig wrote:

> Hi Paul,
> 
> > Last night, I scoped out the work required to get the patch ready to commit.
> > Sorting out the testcases will be the main load since they have grown
> > "organically". I propose to change over to one test for each paragraph of
> > F2018 7.5.6.2/7.5.6.3  and to verify them against
> > the other brands. I suspect that this will allow a weeding out of the
> > existing tests. It will take me a couple of weeks.
> 
> I am a little bit concerned that this might bring us too close to the
> release date. We are down to 22 P1 regressions as of now.
> 
> Richard, what do you think?

While Fortran is not considered release critical it would be bad to
break say the build of SPEC CPU 2017 or Polyhedron very late in the
cycle.  I'd lean towards postponing this to early stage1 and eventually
backport it for GCC 13.2 if you would like this feature to be implemented
for GCC 13.

But it's of course the Fortran maintainers decision.

Even though Fortran isn't release critical we might ask you to revert
if any such severe problems show up.

Thanks,
Richard.

Re: [Patch, fortran] PR37336 finalization

[Thomas Koenig via Fortran]

Hi Paul,

Last night, I scoped out the work required to get the patch ready to 
commit. Sorting out the testcases will be the main load since they have 
grown "organically". I propose to change over to one test for each 
paragraph of F2018 7.5.6.2/7.5.6.3  and to 
verify them against the other brands. I suspect that this will allow a 
weeding out of the existing tests. It will take me a couple of weeks.


I am a little bit concerned that this might bring us too close to the
release date. We are down to 22 P1 regressions as of now.

Richard, what do you think?

Best regards

Thomas

Re: [Patch, fortran] PR37336 finalization

[Paul Richard Thomas via Fortran]

Hi Thomas and Steve,

Last night, I scoped out the work required to get the patch ready to
commit. Sorting out the testcases will be the main load since they have
grown "organically". I propose to change over to one test for each
paragraph of F2018 7.5.6.2/7.5.6.3 and to verify them against the other
brands. I suspect that this will allow a weeding out of the existing tests.
It will take me a couple of weeks.

Could you please review the patch on that self same time scale? I would be
happy to have feedback one file at a time.

Salvatore alerted me to an ICE on valid, which occurs with -fcheck=all.
Eliminating the assert at trans.cc:1101 fixes it. I am not convinced that
the line does anything useful now and so consider it to be erased. I
suspect that future bugs will result from components that are finalizable
and allocatable and so I will be paying close attention to it.

In the course of the last few months, I have found that the associate
construct causes a lot of niggles. Looking at pr87477, I see that I fixed a
number of the dependencies a while since, on a branch other than the
development branch of the time. As a result, the fixes got lost. I will
turn to pr87477 just as soon as pr37336 is done and dusted.

Cheers

Paul


On Tue, 7 Mar 2023 at 14:58, Thomas Koenig  wrote:

> Paul,
>
> first of all, thank you very much indeed for the hard work you put into
> this!  This is a great step for gfortran.
>
> > I can hurry this along to get the patch
> > into 13-branch or I can wait until 14-branch opens.
>
> Personally, I think that this fixes so many bugs, and makes
> the compiler so much better, that I would prefer having it
> in gcc-13.  Finalization was only of very limited use before,
> and the risk of meaningful regressions (short of a build
> failure) is therefore very low.
>
> Again, thanks a lot!
>
> Best regards
>
> Thomas
>
>
>
>

-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

Re: [Patch, fortran] PR37336 finalization

[Steve Kargl via Fortran]

On Tue, Mar 07, 2023 at 03:58:32PM +0100, Thomas Koenig via Fortran wrote:
> Paul,
> 
> first of all, thank you very much indeed for the hard work you put into
> this!  This is a great step for gfortran.

Ditto**2

> > I can hurry this along to get the patch
> > into 13-branch or I can wait until 14-branch opens.
> 
> Personally, I think that this fixes so many bugs, and makes
> the compiler so much better, that I would prefer having it
> in gcc-13.  Finalization was only of very limited use before,
> and the risk of meaningful regressions (short of a build
> failure) is therefore very low.
> 

I agree with Thomas.  The main branch is in stage 4,
which is regression and documentation fixing mode.  I
would think the number of bugs fixed by your patch
can be argued as fixing regressions.  I can set aside 
some time on Saturday to help with a review (if required).

-- 
Steve

Re: [Patch, fortran] PR37336 finalization

[Thomas Koenig via Fortran]

Paul,

first of all, thank you very much indeed for the hard work you put into
this!  This is a great step for gfortran.


I can hurry this along to get the patch
into 13-branch or I can wait until 14-branch opens.


Personally, I think that this fixes so many bugs, and makes
the compiler so much better, that I would prefer having it
in gcc-13.  Finalization was only of very limited use before,
and the risk of meaningful regressions (short of a build
failure) is therefore very low.

Again, thanks a lot!

Best regards

Thomas

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Harald Anlauf via Fortran]

Dear all,

Jerry pointed out to me off-list that I might have left others
with confusion.  Here's a simple example of what I had in my
mind when I wrote the previous mail, and sorry for the TOFU:

module m
  implicit none
  type :: simple
integer :: ind
  contains
final :: destructor1
  end type simple
contains
  subroutine destructor1(self)
type(simple), intent(inout) :: self
  end subroutine destructor1
end

program p
  use m
  type(simple)  :: ThyType = simple(21)
  type(simple), allocatable :: MyTypeArray(:)
  MyTypeArray = [ThyType]
end


With the latest patch version I have from Paul:

-std=f2018 : silent
-std=gnu   : silent (good so far)

-std=f2008 :

foo.f90:18:25:

   18 |   MyTypeArray = [ThyType]
  | 1
Warning: The structure constructor at (1) has been finalized. This feature was 
removed by f08/0011. Use -std=f2018 or -std=gnu to eliminate the finalization.

So the question is do we follow the original f2008 text or f08/0011?
(For reference, see https://j3-fortran.org/doc/year/10/10-202r1.txt
which says:

```
Which is the correct approach?

ANSWER:
Approach 4.  Constructors don't do anything that needs finalization.
```

I was trying to argue that the best user experience would be obtained
by just doing what the interp says, and voting to draw the line between
pre-f08/0011 and f08/0011 / f2018+.

I am open to what should be done for -std=f2003 or -std=legacy, but
then I do not really care, as finalization is not exactly legacy stuff.

Thanks,
Harald


> Gesendet: Montag, 09. Januar 2023 um 21:42 Uhr
> Von: "Harald Anlauf" 
> An: "Paul Richard Thomas" 
> Cc: "Jerry D" , "fortran" 
> Betreff: Aw: Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] 
> Finish derived-type finalization
>
> Hi Paul, all,
>  
> this is certainly better, and I am close to saying "go ahead", and
> "let's fix any fallout later".
> 
> I am still confused about the handling of F2008 backward compatibility,
> even more so after looking at the mentioned interp F08/0011.
> 
> When referring to the published standard, this document really has a lot
> of "this does not seem to make sense." or "This makes even less sense..."
> It appears to be really tough on the F2008 text.
> 
> At the risk of sounding stupid, but what line of interpretation do
> we normally follow?  The published standard as-is, or rather take
> into account the interpretation, even if it says that the published
> document does not make sense?
> 
> If I understood you correctly, you are trying to implement a
> backward compatibility, and the warning you emit refers to the
> pre-interp version.  I haven't looked at the latest standard,
> but I guess you spent a lot of time on it: is there a difference
> between the interp version and the F2018 version?  If not, wouldn't
> your/our life be easier if we focus on no-nonsense interpretations?
> Or is there a convincing reason to support the pre-interp variant?
> 
> (From a practical point of view, a "F2018+ only" compliant
> finalization would be more than most competitors offer... :)
> 
> Thanks,
> Harald
> 
> 
> Gesendet: Samstag, 07. Januar 2023 um 11:57 Uhr
> Von: "Paul Richard Thomas" 
> An: "Harald Anlauf" 
> Cc: "Jerry D" , "fortran" 
> Betreff: Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish 
> derived-type finalization
> 
> Hi All,
>  
> Please find attached a patch for trans-array.cc that does what Harald 
> suggests; ie. finalization of array and structure constructors only occurs 
> with -std=f2003/8. Two versions of finalize_38.f90 are attached. One which 
> tests -std=gnu/f20018 and the other -std=f2008.
>  
> Frankly, I think that this is better. Finalization of these expressions must 
> be handled with a lot of care and was deleted by f2018 for good reasons. 
> Above all else, the results do not represent defined entities and so it does 
> not really make sense to finalize them. My vote is to go with this version of 
> the patch.
>  
> I am struggling a bit with a nit in finalize_45. One of the other processors 
> appears to nullify the pointer component of the result of construct_t during 
> finalization of the result. I can see the sense in this but do not find any 
> requirement to do so in the standard.
>  
> Given the scale of the overall patch, I am beginning to have a lot of 
> sympathy with Thomas's suggestion that the finalization calls should be moved 
> to the front end! I will take a quick look to see how easy this would be to 
> implement.
>  
> Regards
>  
> Paul
>   
> 
> On Fri, 6 Jan 2023 at 08:34, Harald Anlauf via Fortran 
> mailto:fortran@gcc.

Aw: Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Harald Anlauf via Fortran]

Hi Paul, all,
 
this is certainly better, and I am close to saying "go ahead", and
"let's fix any fallout later".

I am still confused about the handling of F2008 backward compatibility,
even more so after looking at the mentioned interp F08/0011.

When referring to the published standard, this document really has a lot
of "this does not seem to make sense." or "This makes even less sense..."
It appears to be really tough on the F2008 text.

At the risk of sounding stupid, but what line of interpretation do
we normally follow?  The published standard as-is, or rather take
into account the interpretation, even if it says that the published
document does not make sense?

If I understood you correctly, you are trying to implement a
backward compatibility, and the warning you emit refers to the
pre-interp version.  I haven't looked at the latest standard,
but I guess you spent a lot of time on it: is there a difference
between the interp version and the F2018 version?  If not, wouldn't
your/our life be easier if we focus on no-nonsense interpretations?
Or is there a convincing reason to support the pre-interp variant?

(From a practical point of view, a "F2018+ only" compliant
finalization would be more than most competitors offer... :)

Thanks,
Harald


Gesendet: Samstag, 07. Januar 2023 um 11:57 Uhr
Von: "Paul Richard Thomas" 
An: "Harald Anlauf" 
Cc: "Jerry D" , "fortran" 
Betreff: Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish 
derived-type finalization

Hi All,
 
Please find attached a patch for trans-array.cc that does what Harald suggests; 
ie. finalization of array and structure constructors only occurs with 
-std=f2003/8. Two versions of finalize_38.f90 are attached. One which tests 
-std=gnu/f20018 and the other -std=f2008.
 
Frankly, I think that this is better. Finalization of these expressions must be 
handled with a lot of care and was deleted by f2018 for good reasons. Above all 
else, the results do not represent defined entities and so it does not really 
make sense to finalize them. My vote is to go with this version of the patch.
 
I am struggling a bit with a nit in finalize_45. One of the other processors 
appears to nullify the pointer component of the result of construct_t during 
finalization of the result. I can see the sense in this but do not find any 
requirement to do so in the standard.
 
Given the scale of the overall patch, I am beginning to have a lot of sympathy 
with Thomas's suggestion that the finalization calls should be moved to the 
front end! I will take a quick look to see how easy this would be to implement.
 
Regards
 
Paul
  

On Fri, 6 Jan 2023 at 08:34, Harald Anlauf via Fortran 
mailto:fortran@gcc.gnu.org]> wrote:Hi Jerry,

> Gesendet: Freitag, 06. Januar 2023 um 04:08 Uhr
> Von: "Jerry D" mailto:jvdelis...@gmail.com]>
> An: "Harald Anlauf" mailto:anl...@gmx.de]>, "fortran" 
> mailto:fortran@gcc.gnu.org]>
> Betreff: Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish 
> derived-type finalization
>
> On 1/5/23 1:14 PM, Harald Anlauf via Fortran wrote:
> > Resending as plain text, as the original version did not appear on the 
> > fortran list...
> >   
> >
> > Gesendet: Donnerstag, 05. Januar 2023 um 22:10 Uhr
> > Von: "Harald Anlauf" mailto:anl...@gmx.de]>
> > An: "Paul Richard Thomas" 
> > mailto:paul.richard.tho...@gmail.com]>
> > Cc: "fortran@gcc.gnu.org[mailto:fortran@gcc.gnu.org]; 
> > mailto:fortran@gcc.gnu.org]>, "Alessandro Fanfarillo" 
> > mailto:alessandro.fanfari...@gmail.com]>, 
> > "Andrew Benson" 
> > mailto:aben...@carnegiescience.edu]>, "Thomas 
> > Koenig" mailto:tkoe...@gcc.gnu.org]>, "Damian Rouson" 
> > 
> > Betreff: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish 
> > derived-type finalization
> >
> > Dear Paul, all,
> >   
> > I had a first look at the patch and the testcases, and I really look 
> > forward to getting this into gfortran.
> >   
> > A few questions surfaced when playing with it, which is why am asking for 
> > others to comment.
> >   
> > Testcase finalize_38.f90 exhibits a (potential) discrepancy to my 
> > expections when playing with options -std=f2018 and -std=gnu (the default).
> >   
> > What is the expected behavior of -std=gnu?  My expectation is that -std=gnu 
> > always corresponds to the latest implemented standard (currently F2018), 
> > except for possibly allowing for GNU-extensions.  This might imply that 
> > corrigenda to a standard or a newer version may lead (over time) to an 
> > adjustment of the behavior.  Any opinions o

Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Paul Richard Thomas via Fortran]

Hi Thomas,

I was thinking of a function in resolve.cc, similar
to generate_component_assignments that would generate the final call and,
where necessary, generate a temporary and place rhs finalization after the
assignment. Since this would only involve ordinary assignment and
subroutine calls, I think that it is compatible both with forall and where
constructs.

I guess that I should check whether or not generate_component_assignments
should not be placed within frontend_passes.cc. This part of resolve.cc
precedes your efforts, I believe.

Generating the final calls in the frontend would eliminate a substantial
amount of rather opaque code.

Best regards

Paul


On Sun, 8 Jan 2023 at 12:03, Thomas Koenig  wrote:

> Hi Paul,
>
> > What causes the ICES?
>
> There were a few PRs along this line.  Usually, it is the
> front-end pass inserting code which is illegal Fortran, and
> the later stages then asserting that it doesn't happen.
>
> Here are a few examples:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690 (function
> elimination in OMP Workshare)
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564 (forall)
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69154 (matmul
> in where)
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69742 (in
> associate).
>
> If you want to do the finalization of function results via
> a front end pass, creating a variable and then assigning it
> from within these constructs can cause these kinds of problems.
>
> Best regards
>
> Thomas
>


-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Thomas Koenig via Fortran]

Hi Paul,


What causes the ICES?


There were a few PRs along this line.  Usually, it is the
front-end pass inserting code which is illegal Fortran, and
the later stages then asserting that it doesn't happen.

Here are a few examples:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690 (function
elimination in OMP Workshare)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564 (forall)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69154 (matmul
in where)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69742 (in
associate).

If you want to do the finalization of function results via
a front end pass, creating a variable and then assigning it
from within these constructs can cause these kinds of problems.

Best regards

Thomas

Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Paul Richard Thomas via Fortran]

Hi Thomas,

What causes the ICES?

Cheers

Paul


On Sat, 7 Jan 2023 at 15:28, Thomas Koenig  wrote:

> Hi Paul,
>
> first, thanks for taking on this rather monumental task!
>
> > Given the scale of the overall patch, I am beginning to have a lot of
> > sympathy with Thomas's suggestion that the finalization calls should be
> > moved to the front end! I will take a quick look to see how easy this
> would
> > be to implement.
>
> There is one drawback if you do this in the front end:  There are a few
> places where it is not possible to add code without running into ICEs
> later, like WHERE/ELSEWHERE, which is why fronend_passes.cc keeps track
> of these things.
>
> Best regards
>
> Thomas
>


-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Thomas Koenig via Fortran]

Hi Paul,

first, thanks for taking on this rather monumental task!


Given the scale of the overall patch, I am beginning to have a lot of
sympathy with Thomas's suggestion that the finalization calls should be
moved to the front end! I will take a quick look to see how easy this would
be to implement.


There is one drawback if you do this in the front end:  There are a few
places where it is not possible to add code without running into ICEs
later, like WHERE/ELSEWHERE, which is why fronend_passes.cc keeps track
of these things.

Best regards

Thomas

Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Paul Richard Thomas via Fortran]

Hi All,

Please find attached a patch for trans-array.cc that does what Harald
suggests; ie. finalization of array and structure constructors only occurs
with -std=f2003/8. Two versions of finalize_38.f90 are attached. One which
tests -std=gnu/f20018 and the other -std=f2008.

Frankly, I think that this is better. Finalization of these expressions
must be handled with a lot of care and was deleted by f2018 for good
reasons. Above all else, the results do not represent defined entities and
so it does not really make sense to finalize them. My vote is to go with
this version of the patch.

I am struggling a bit with a nit in finalize_45. One of the other
processors appears to nullify the pointer component of the result
of construct_t during finalization of the result. I can see the sense in
this but do not find any requirement to do so in the standard.

Given the scale of the overall patch, I am beginning to have a lot of
sympathy with Thomas's suggestion that the finalization calls should be
moved to the front end! I will take a quick look to see how easy this would
be to implement.

Regards

Paul


On Fri, 6 Jan 2023 at 08:34, Harald Anlauf via Fortran 
wrote:

> Hi Jerry,
>
> > Gesendet: Freitag, 06. Januar 2023 um 04:08 Uhr
> > Von: "Jerry D" 
> > An: "Harald Anlauf" , "fortran" 
> > Betreff: Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03]
> Finish derived-type finalization
> >
> > On 1/5/23 1:14 PM, Harald Anlauf via Fortran wrote:
> > > Resending as plain text, as the original version did not appear on the
> fortran list...
> > >
> > >
> > > Gesendet: Donnerstag, 05. Januar 2023 um 22:10 Uhr
> > > Von: "Harald Anlauf" 
> > > An: "Paul Richard Thomas" 
> > > Cc: "fortran@gcc.gnu.org" , "Alessandro
> Fanfarillo" , "Andrew Benson" <
> aben...@carnegiescience.edu>, "Thomas Koenig" ,
> "Damian Rouson" 
> > > Betreff: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish
> derived-type finalization
> > >
> > > Dear Paul, all,
> > >
> > > I had a first look at the patch and the testcases, and I really look
> forward to getting this into gfortran.
> > >
> > > A few questions surfaced when playing with it, which is why am asking
> for others to comment.
> > >
> > > Testcase finalize_38.f90 exhibits a (potential) discrepancy to my
> expections when playing with options -std=f2018 and -std=gnu (the default).
> > >
> > > What is the expected behavior of -std=gnu?  My expectation is that
> -std=gnu always corresponds to the latest implemented standard (currently
> F2018), except for possibly allowing for GNU-extensions.  This might imply
> that corrigenda to a standard or a newer version may lead (over time) to an
> adjustment of the behavior.  Any opinions on it?  Do we need to always test
> (in the testsuite) for compliance with older standards?
> > >
> >
> > My understanding is that -std=gnu tends to be the least restrictive and
> > will allow finalize_38.f90 to compile possibly with warnings. The
> > warnings are to allow the user to know thay are out of current
> > compliance, but we should not fail on code that was previously compliant
> > and less we specify -std=f2018 which is more restrictive.
>
> So if e.g. finalize_38.f90 compiles without warnings with -std=f2018,
> it should also compile without warnings with -std=gnu, right?
>
> Harald
>
>
> > Jerry
> >
> >
>


-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
! { dg-do run }
!
! Test finalization on intrinsic assignment (F2018 (7.5.6.3))
! With -std=gnu, no finalization of array or structure constructors should occur.
! See finalize_38a.f90 for the result with f2008.
! Tests fix for PR64290 as well.
!
module testmode
  implicit none

  type :: simple
integer :: ind
  contains
final :: destructor1, destructor2
  end type simple

  type, extends(simple) :: complicated
real :: rind
  contains
final :: destructor3, destructor4
  end type complicated

  integer :: check_scalar
  integer :: check_array(4)
  real :: check_real
  real :: check_rarray(4)
  integer :: final_count = 0

contains

  subroutine destructor1(self)
type(simple), intent(inout) :: self
check_scalar = self%ind
check_array = 0
final_count = final_count + 1
  end subroutine destructor1

  subroutine destructor2(self)
type(simple), intent(inout) :: self(:)
check_scalar = 0
check_array(1:size(self, 1)) = self%ind
final_count = final_count + 1
  end subroutine destructor2

  subroutine destructor3(self)
type(complicated), intent(inout) :: s

Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Harald Anlauf via Fortran]

Hi Jerry,

> Gesendet: Freitag, 06. Januar 2023 um 04:08 Uhr
> Von: "Jerry D" 
> An: "Harald Anlauf" , "fortran" 
> Betreff: Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish 
> derived-type finalization
>
> On 1/5/23 1:14 PM, Harald Anlauf via Fortran wrote:
> > Resending as plain text, as the original version did not appear on the 
> > fortran list...
> >   
> > 
> > Gesendet: Donnerstag, 05. Januar 2023 um 22:10 Uhr
> > Von: "Harald Anlauf" 
> > An: "Paul Richard Thomas" 
> > Cc: "fortran@gcc.gnu.org" , "Alessandro Fanfarillo" 
> > , "Andrew Benson" 
> > , "Thomas Koenig" , 
> > "Damian Rouson" 
> > Betreff: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish 
> > derived-type finalization
> > 
> > Dear Paul, all,
> >   
> > I had a first look at the patch and the testcases, and I really look 
> > forward to getting this into gfortran.
> >   
> > A few questions surfaced when playing with it, which is why am asking for 
> > others to comment.
> >   
> > Testcase finalize_38.f90 exhibits a (potential) discrepancy to my 
> > expections when playing with options -std=f2018 and -std=gnu (the default).
> >   
> > What is the expected behavior of -std=gnu?  My expectation is that -std=gnu 
> > always corresponds to the latest implemented standard (currently F2018), 
> > except for possibly allowing for GNU-extensions.  This might imply that 
> > corrigenda to a standard or a newer version may lead (over time) to an 
> > adjustment of the behavior.  Any opinions on it?  Do we need to always test 
> > (in the testsuite) for compliance with older standards?
> >   
> 
> My understanding is that -std=gnu tends to be the least restrictive and 
> will allow finalize_38.f90 to compile possibly with warnings. The 
> warnings are to allow the user to know thay are out of current 
> compliance, but we should not fail on code that was previously compliant 
> and less we specify -std=f2018 which is more restrictive.

So if e.g. finalize_38.f90 compiles without warnings with -std=f2018,
it should also compile without warnings with -std=gnu, right?

Harald


> Jerry
> 
>

Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Jerry D via Fortran]

On 1/5/23 1:14 PM, Harald Anlauf via Fortran wrote:

Resending as plain text, as the original version did not appear on the fortran 
list...
  


Gesendet: Donnerstag, 05. Januar 2023 um 22:10 Uhr
Von: "Harald Anlauf" 
An: "Paul Richard Thomas" 
Cc: "fortran@gcc.gnu.org" , "Alessandro Fanfarillo" , "Andrew 
Benson" , "Thomas Koenig" , "Damian Rouson" 

Betreff: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish 
derived-type finalization

Dear Paul, all,
  
I had a first look at the patch and the testcases, and I really look forward to getting this into gfortran.
  
A few questions surfaced when playing with it, which is why am asking for others to comment.
  
Testcase finalize_38.f90 exhibits a (potential) discrepancy to my expections when playing with options -std=f2018 and -std=gnu (the default).
  
What is the expected behavior of -std=gnu?  My expectation is that -std=gnu always corresponds to the latest implemented standard (currently F2018), except for possibly allowing for GNU-extensions.  This might imply that corrigenda to a standard or a newer version may lead (over time) to an adjustment of the behavior.  Any opinions on it?  Do we need to always test (in the testsuite) for compliance with older standards?
  


My understanding is that -std=gnu tends to be the least restrictive and 
will allow finalize_38.f90 to compile possibly with warnings. The 
warnings are to allow the user to know thay are out of current 
compliance, but we should not fail on code that was previously compliant 
and less we specify -std=f2018 which is more restrictive.


Jerry

Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Harald Anlauf via Fortran]

Resending as plain text, as the original version did not appear on the fortran 
list...
 

Gesendet: Donnerstag, 05. Januar 2023 um 22:10 Uhr
Von: "Harald Anlauf" 
An: "Paul Richard Thomas" 
Cc: "fortran@gcc.gnu.org" , "Alessandro Fanfarillo" 
, "Andrew Benson" 
, "Thomas Koenig" , "Damian 
Rouson" 
Betreff: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish 
derived-type finalization

Dear Paul, all,
 
I had a first look at the patch and the testcases, and I really look forward to 
getting this into gfortran.
 
A few questions surfaced when playing with it, which is why am asking for 
others to comment.
 
Testcase finalize_38.f90 exhibits a (potential) discrepancy to my expections 
when playing with options -std=f2018 and -std=gnu (the default).
 
What is the expected behavior of -std=gnu?  My expectation is that -std=gnu 
always corresponds to the latest implemented standard (currently F2018), except 
for possibly allowing for GNU-extensions.  This might imply that corrigenda to 
a standard or a newer version may lead (over time) to an adjustment of the 
behavior.  Any opinions on it?  Do we need to always test (in the testsuite) 
for compliance with older standards?
 
If there is a change in the behavior between versions of the standard: should 
the compiler give a warning, when, and if so, is there a preferred flag that 
should control that warning (-pedantic or rather -Wsurprising or whatever)?
 

Thanks,
Harald
 

Gesendet: Montag, 02. Januar 2023 um 14:15 Uhr
Von: "Paul Richard Thomas" 
An: "fortran@gcc.gnu.org" 
Cc: "Harald Anlauf" , "Alessandro Fanfarillo" 
, "Andrew Benson" 
, "Thomas Koenig" , "Damian 
Rouson" 
Betreff: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type 
finalization

Hi All,
 
Happy new year!
 
This thread broke off in February last year, as did my effort to resolve all 
the issues. However, prodded by Damian, I picked up the mantle again about a 
month ago.
 
Please consider this posting to be a placeholder. All the dependencies of 
PR37366 appear to be fixed although some minor issues remain and some 
divergences with the other brands. I will be contacting the vendors of the 
other brands today or tomorrow and will try to achieve some resolution with 
them. In the meantime, I will break the patch down to half a dozen more 
digestible chunks and will aim to submit formally in a week or so.
 
Of the remaining issues:
Function results of finalizable type with zero components confound the 
gimplifier: see PR65347 comment 3.
finalize_38.f90 loses 38 bytes in 4 blocks and has a load of invalid writes.
finalize_49.f90 has a number of invalid writes.
 
Please give the patch a whirl and any feedback that you might have would be 
very welcome.
 
Cheers
 
Paul
 
Fortran:Implement missing finalization features [PR37336]

2022-02-02  Paul Thomas  mailto:pa...@gcc.gnu.org]>

gcc/fortran
PR fortran/103854
* class.cc (has_finalizer_component): Do not return true for
procedure pointer components.

PR fortran/96122
* class.cc (finalize_component): Include the missing arguments
in the call to the component's finalizer wrapper.

PR fortran/37336
* class.cc (finalizer_insert_packed_call): Remove the redundant
argument in the call to the final subroutine.
(generate_finalization_wrapper): Add support for assumed rank
finalizers.
(gfc_may_be_finalized): New helper function.
* dump_parse_tree.cc (show_expr): Mark expressions with
must_finalize set.
* gfortran.h : Add prototype for gfc_may_be_finalized.
* resolve.cc (resolve_where, gfc_resolve_where_code_in_forall,
gfc_resolve_forall_body, gfc_resolve_code): Check that the op
code is still EXEC_ASSIGN. If it is set lhs to must finalize.
(generate_component_assignments): Set must_finalize if needed.
(gfc_resolve_finalizers): Error if assumed rank finalizer is
not the only one. Warning on lack of scalar finalizer modified
to account for assumed rank finalizers.
(resolve_symbol): Set referenced an unreferenced symbol that
will be finalized.
* trans-array.cc (gfc_trans_array_constructor_value): Add code
to finalize the constructor result. Warn that this feature was
removed in F2018 and that it is suppressed by -std=2018.
(trans_array_constructor): Add finalblock, pass to previous
and apply to loop->post if filled.
(gfc_add_loop_ss_code): Add se finalblock to outer loop post.
(gfc_trans_array_cobounds, gfc_trans_array_bounds): Add any
generated finalization code to the main block.
(structure_alloc_comps): Add boolean argument to suppress
finalization and use it for calls from
gfc_deallocate_alloc_comp_no_caf. Otherwise it defaults to
false. Add a second, additional boolean argument to nullify
pointer components and use it in gfc_copy_alloc_comp_del_ptrs.
(gfc_copy_alloc_comp_del_ptrs): New wrapper for
structure_alloc_comps.
(gfc_alloc_allocatable_for_assignment): Suppress finalization
b

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Paul Richard Thomas via Fortran]

Hi Harald and Thomas,

Thank you for your contributions to understanding the interpretation by
different vendors of the F2018 requirements for finalization. While it does
appear to be rather chaotic, the differences are down to a small number of
"features" of each compiler.

Before describing my interpretation of the behaviour of the offerings from
other vendors, I should remark briefly about where I am with gfortran. I
now have a patch that handles derived types correctly according to F2018
7.5.6.2 and 7.5.6.3, modulo the ambiguous requirement for the handling of
parent components that I will come to when discussing ifort. I have a patch
ready to fix this, should Intel's interpretation be correct. I have not
moved on to class finalization yet because there are memory leaks connected
with finalization of function results that I have yet to pin down. Also,
finalization of function results within array and structure constructors is
yet to come. Once I have it all working, I will break up the patch into a
number of stages to make it more digestible for review. However, just in
case I fall under the proverbial bus, I have attached the patch for
reference.

Turning to the results from the other vendors:

Cray: Seemingly, the only difference in interpretation concerns the
finalization of structure constructors. 7.5.6.3 paragraphs 5 and 6 only
mention function results. Having scoured the standard for guidance, I have
only found Note 7.57: "name(...) ...snip... is interpreted as a structure
constructor only if it cannot be interpreted as a generic function
reference." From this, I take it that a structure constructor is distinct
from a function reference and, since not mentioned in 7.5.6.3, the result
should not be finalized.

nagfor 7.1: The NAG offering seems to be a bit inconsistent in the
finalization of function results. It is missing in assignment 4 and suffers
a surfeit in assignment 5. The two extras in assignment 5 seem to be
mangled. As far as I can tell, these are problems of implementation rather
than interpretation.

ifort: In all the versions tested, assignment 1 generates, contrary to the
standard, a finalization of an unallocated allocated 'var'. The other
difference from gfortran with the patch applied is in the finalization of
the parent component in the finalization of arrays of extended types. ifort
makes use of the scalar finalizer, whereas all the other compilers use the
array finalizer. In fairness to the folk at Intel, I think that there is an
ambiguity in 7.5.6.2 -

"(2) All finalizable components that appear in the type definition are
finalized in a processor-dependent order. If the entity being finalized is
an array, each finalizable component of each element of that entity is
finalized separately.
(3) If the entity is of extended type and the parent type is finalizable,
the parent component is finalized."

The separate mention of the parent component in (3) rather than in (2)
saying, "..each finalizable component, including the parent component,..."
implies that it is in some way different. I think that an interpretation
request is in order.

I will be unavailable to do any gfortran work for two weeks now but will
complete this work then.

Best regards and thanks again.

Paul


On Thu, 17 Feb 2022 at 21:23, Thomas Koenig  wrote:

> Hi Paul,
>
> > I have gone back to the start and have gone through finalizable derived
> > type assignments with the F2018 in hand. I have had a dreadful time with
> > direct by reference function calls and still am struggling with
> assignment
> > number 6 in the attached. I would be very grateful if you would run this
> > testcase for the other brands.
>
> This is the output of nagfor 7.1, no idea how correct this is.
>
> Best regards
>
> Thomas
>
>   At start of program: final_count =0
>   ***
>
>   1st assignment: No finalization because MyType unallocated.
>   After 1st assignment(var not allocated): final_count =0(0)
>   ***
>
>   2nd assignment: MyType(=simple(1,MyType) finalized before assignment
>   finalize simple - Mytype2%ind =1
>   After 2nd assignment(var allocated): final_count =1(1)
>   ***
>
>   3rd assignment: MyTypeArray(%ind = [41 42]) finalized before assignment
>
>   finalize simple(:) - MyTypeArray%ind=   42  43
>   After 3rd assignment(array var allocated): final_count =1(1)
>   ***
>
>   Deallocation generates final call with self = simple (21, ThyType)
>   4th assignment: MyTypeArray finalized before assignment
>   Mtype finalized before assignment with self = simple (11, MyType)
>   Function result finalized after assignment with self = simple (99,
> MyType)
>
>   finalize simple - ThyType%ind =   21
>   finalize simple - MyType%ind =   11
>   After 4th 

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Thomas Koenig via Fortran]

Hi Paul,


I have gone back to the start and have gone through finalizable derived
type assignments with the F2018 in hand. I have had a dreadful time with
direct by reference function calls and still am struggling with assignment
number 6 in the attached. I would be very grateful if you would run this
testcase for the other brands.


This is the output of nagfor 7.1, no idea how correct this is.

Best regards

Thomas

 At start of program: final_count =0
 ***

 1st assignment: No finalization because MyType unallocated.
 After 1st assignment(var not allocated): final_count =0(0)
 ***

 2nd assignment: MyType(=simple(1,MyType) finalized before assignment
 finalize simple - Mytype2%ind =1
 After 2nd assignment(var allocated): final_count =1(1)
 ***

 3rd assignment: MyTypeArray(%ind = [41 42]) finalized before assignment

 finalize simple(:) - MyTypeArray%ind=   42  43
 After 3rd assignment(array var allocated): final_count =1(1)
 ***

 Deallocation generates final call with self = simple (21, ThyType)
 4th assignment: MyTypeArray finalized before assignment
 Mtype finalized before assignment with self = simple (11, MyType)
 Function result finalized after assignment with self = simple (99, MyType)

 finalize simple - ThyType%ind =   21
 finalize simple - MyType%ind =   11
 After 4th assignment(array var allocated) :final_count =2(3)
 ***

 5th assignment: MyTypeArray finalized before assignment
 1] First finalization is of 'res' in constructor3 with:
 Self = [complicated (-1, constructor3, 0.0), complicated (-1, 
ThyTypeArra1, 0.0)]
 2] ThyTypeArray is finalized before assignment and after evaluation of 
constructor3

 Self = [3 times complicated (-1, ThyTypeArra1,0.0)]
 3] Function result finalized after assignment with
 Self = [complicated (-1, ThyTypeArra2, 0.0), complicated (-1, 
ThyTypeArra2, 0.0)]


 constructor3: final_count =  0
 finalize complicated(2) - constructor3 =0   0  0.00  0.00
 finalize simple(:) - constructor3%ind=0   0
 finalize complicated(3) - ThyTypeArra1 =   -1  -1  -1  0.00  0.00  0.00
 finalize simple(:) - ThyTypeArra1%ind=   -1  -1  -1
 finalize complicated(2) - ThyTypeArra2 =1   3  2.00  4.00
 finalize simple(:) - ThyTypeArra2%ind=1   3
 finalize complicated(2) - IypeArra2 =    3  2.00  4.00
 finalize simple(:) - IypeArra2%ind=    3
 finalize complicated(2) - IypeArra2 =    3  2.00  4.00
 finalize simple(:) - IypeArra2%ind=    3
 After 5th assignment(array var allocated):  10(6)

 ***
 Deallocate ThyTypeArray.
 finalize complicated(2) - ThyTypeArra2 =1   3  2.00  4.00
 finalize simple(:) - ThyTypeArra2%ind=1   3

 ***
 6th assignment: A repeat of the previous with an allocatable function 
result.

 This should give the same result as the 5th assignment.

 constructor4: final_count =  0
 finalize complicated(2) - constructor4 =1   1  1.00  1.00
 finalize simple(:) - constructor4%ind=1   1
 finalize complicated(2) - ThyTypeArra2 =1   3  2.00  4.00
 finalize simple(:) - ThyTypeArra2%ind=1   3
 finalize complicated(3) - ThyTypeArra1 =   -1  -1  -1  0.00  0.00  0.00
 finalize simple(:) - ThyTypeArra1%ind=   -1  -1  -1
 After 6th assignment(array var allocated):   6(6)

 ***
 Deallocations at end

 finalize simple - MyType%ind =   99
 After 1st deallocation: 1
 finalize simple - ThyType2%ind =   22
 After 2nd deallocation: 2
 finalize simple(:) - ThyType%ind=   21  22
 After 3rd deallocation: 3

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Harald Anlauf via Fortran]

Hi Paul,

Am 16.02.22 um 19:49 schrieb Paul Richard Thomas via Fortran:

Hi Harald and Jerry,

I have gone back to the start and have gone through finalizable derived
type assignments with the F2018 in hand. I have had a dreadful time with
direct by reference function calls and still am struggling with assignment
number 6 in the attached. I would be very grateful if you would run this
testcase for the other brands.


please find attached the output of crayftn-12.0.3, NAG 7.0, and
Intel 2021.5.0, always both default optimization and -g.

The junk in the output for some brands is reproducible.  :-(


As soon as I fix the 6th assignment, I will get on to class assignments.


Good luck, then.  ;-)

Cheers,
Harald
 finalize simple - ThyType%ind =   21
 finalize simple - ThyType2%ind =   22
 At start of program: final_count =2
 ***
 
 1st assignment: No finalization because MyType unallocated.
 After 1st assignment(var not allocated): final_count =2(0)
 ***
 
 2nd assignment: MyType(=simple(1,MyType) finalized before assignment
 finalize simple - Mytype2%ind =1
 After 2nd assignment(var allocated): final_count =1(1)
 ***
 
 3rd assignment: MyTypeArray(%ind = [41 42]) finalized before assignment
 
 finalize simple(:) - MyTypeArray%ind=   42  43
 finalize simple(:) - ThyType%ind=   21  22
 After 3rd assignment(array var allocated): final_count =2(1)
 ***
 
 Deallocation generates final call with self = simple (21, ThyType)
 4th assignment: MyTypeArray finalized before assignment
 Mtype finalized before assignment with self = simple (11, MyType)
 Function result finalized after assignment with self = simple (99, MyType)
 
 finalize simple - ThyType%ind =   21
 finalize simple - MyType%ind =   11
 finalize simple - MyType%ind =   99
 finalize simple - MyType%ind =   99
 After 4th assignment(array var allocated) :final_count =4(3)
 ***
 
 5th assignment: MyTypeArray finalized before assignment
 1] First finalization is of 'res' in constructor3 with:
 Self = [complicated (-1, constructor3, 0.0), complicated (-1, ThyTypeArra1, 
0.0)]
 2] ThyTypeArray is finalized before assignment and after evaluation of 
constructor3
 Self = [3 times complicated (-1, ThyTypeArra1,0.0)]
 3] Function result finalized after assignment with
 Self = [complicated (-1, ThyTypeArra2, 0.0), complicated (-1, ThyTypeArra2, 
0.0)]
 
 finalize complicated - ThyTypeArra1 =   -1  0.00
 finalize simple - ThyTypeArra1%ind =   -1
 constructor3: final_count =  2
 finalize complicated(2) - constructor3 =0  41  0.00  0.00
 finalize simple(:) - constructor3%ind=0  41
 finalize complicated(2) - ThyTypeArra2 =1   3  2.00  4.00
 finalize simple(:) - ThyTypeArra2%ind=1   3
 finalize complicated(2) - ThyTypeArra2 =1   3  2.00  4.00
 finalize simple(:) - ThyTypeArra2%ind=1   3
 After 5th assignment(array var allocated):   8(6)
 
 ***
 Deallocate ThyTypeArray.
 finalize complicated(2) - ThyTypeArra2 =1   3  2.00  4.00
 finalize simple(:) - ThyTypeArra2%ind=1   3
 
 ***
 6th assignment: A repeat of the previous with an allocatable function result.
 This should give the same result as the 5th assignment.
 
 finalize complicated - ThyTypeArra1 =   -1  0.00
 finalize simple - ThyTypeArra1%ind =   -1
 constructor4: final_count =  2
 finalize complicated - constructor3 =1  1.00
 finalize simple - constructor3%ind =1
 finalize complicated(2) - ThyTypeArra2 =1   3  2.00  4.00
 finalize simple(:) - ThyTypeArra2%ind=1   3
 finalize complicated(2) - ThyTypeArra2 =1   3  2.00  4.00
 finalize simple(:) - ThyTypeArra2%ind=1   3
 After 6th assignment(array var allocated):   8(6)
 
 ***
 Deallocations at end
 
 finalize simple - MyType%ind =   99
 After 1st deallocation: 1
 finalize simple - ThyType2%ind =   22
 After 2nd deallocation: 2
 finalize simple(:) - ThyType%ind=   21  22
 After 3rd deallocation: 3


out.intel
Description: Binary data
 At start of program: final_count =0
 ***
 
 1st assignment: No finalization because MyType unallocated.
 After 1st assignment(var not allocated): final_count =0(0)
 ***
 
 2nd assignment: MyType(=simple(1,MyType) finalized before assignment
 finalize simple - Mytype2%ind =1
 After 2nd assignment(var allocated): final_count =1(1)
 ***
 
 3rd assignment: 

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Paul Richard Thomas via Fortran]

Hi Harald and Jerry,

I have gone back to the start and have gone through finalizable derived
type assignments with the F2018 in hand. I have had a dreadful time with
direct by reference function calls and still am struggling with assignment
number 6 in the attached. I would be very grateful if you would run this
testcase for the other brands.

As soon as I fix the 6th assignment, I will get on to class assignments.

Best regards

Paul


On Fri, 11 Feb 2022 at 21:59, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:

> Hi Harald and Jerry,
>
> I am reworking my way through, line by line wit F2018 in hand. Up to test
> with offset 70, NAG looks to be right. I introduced an assignment with a
> direct by ref function call, which doesn't finalise at the moment. Class
> entities are yet to come. I'll report back early next week.
>
> Thanks for all the help. I have (re)learned to read the standard very
> carefully.
>
> Best regards
>
> Paul
>
>
> On Fri, 11 Feb 2022, 21:08 Harald Anlauf,  wrote:
>
>> Hi Paul,
>>
>> Am 11.02.22 um 10:08 schrieb Paul Richard Thomas via Fortran:
>> > Your "stupid questions" are not at all stupid. The finalization of
>> > 'variable' that occurs in your testcase demonstrates that the
>> finalization
>> > with my patch is occurring at the wrong time. I now see that NAG is
>> correct
>> > on this.
>> >
>> > Please press on with the questions!
>>
>> Jerry's suggestion to add lots of prints turned out to be really
>> enlightening with regard to observable behavior.  I rewrote the
>> testcase again and placed the interesting stuff into a subroutine.
>> This way one can distinguish what actually happens during program
>> start, entering and leaving a subroutine.
>>
>> I encountered the least surprises (= none) with NAG 7.0 here.
>> For reference this is the output:
>>
>>   At start of program : 0
>>
>>   Enter sub   : 0
>>   After 1st allocation: 0
>>   After 2nd allocation: 0
>>   Checking MyType% ind: 21
>>   Checking MyType2%ind: 22
>>   Deallocate MyType   : 0
>>   # Leave desctructor1: 1 21
>>   * MyType deallocated: 1
>>   (kept MyType2 for automatic deallocation on return from sub)
>>   Leave sub   : 1
>>   # Leave desctructor1: 2 22
>>
>>   After sub   : 2
>>
>> To make it short: the destructor is called only when deallocation
>> occurs, either explicitly or automatically.
>>
>>
>> Intel 2021.5.0:
>>
>>   At start of program :   0
>>
>>   Enter sub   :   0
>>   # Leave desctructor1:   1   0
>>   After 1st allocation:   1
>>   # Leave desctructor1:   2   0
>>   After 2nd allocation:   2
>>   Checking MyType% ind:  21
>>   Checking MyType2%ind:  22
>>   Deallocate MyType   :   2
>>   # Leave desctructor1:   3  21
>>   * MyType deallocated:   3
>>   (kept MyType2 for automatic deallocation on return from sub)
>>   Leave sub   :   3
>>   # Leave desctructor1:   4  21
>>   # Leave desctructor1:   5  22
>>   # Leave desctructor1:   6  22
>>
>>   After sub   :   6
>>
>> So after entering the subroutine, the destructor is called twice,
>> but for unknown reasons element ind, which I had expected to be
>> either default-initialized to -1, or explicitly to 21 or 22, is 0.
>> The places where this happens seem to be the assignments of
>> MyType and MyType2.
>>
>> Furthermore, variable MyType is finalized on return from sub,
>> although it is already deallocated, and MyType2 appears to
>> get finalized twice automatically.
>>
>> I have no idea how this can get justified...
>>
>>
>> Crayftn 12.0.2: in order to make the output easier to understand,
>> I chose to reset final_count twice.  This will become clear soon.
>>
>>   # Leave desctructor1: 1,  20
>>
>>   At start of program : 1
>>   +++ Resetting final_count for Cray Fortran : Version 12.0.2
>>
>>   # Leave desctructor1: 1,  21
>>   # Leave desctructor1: 2,  22
>>   Enter sub   : 2
>>   +++ Resetting final_count for Cray Fortran : Version 12.0.2
>>   After 1st allocation: 0
>>   After 2nd allocation: 0
>>   Checking MyType% ind: -21
>>   Checking MyType2%ind: 22
>>   Deallocate MyType   : 0
>>   # Leave desctructor1: 1,  -21
>>   * MyType deallocated: 1
>>   (kept MyType2 for automatic deallocation on return from sub)
>>   Leave sub   : 1
>>   # Leave desctructor1: 2,  22
>>
>>   After sub   : 2
>>
>> So it appears that Cray is calling the destructor for each declaration
>> where a constructor is involved, or the like.  Even if this is a
>> parameter declaration, like in the main.  Resetting the counter for
>> the first time.
>>
>> On entering sub, I see now two finalizations before the first print.
>> Resetting the counter for the second time.
>>
>> But then the assignments do not invoke finalization, where Intel did.
>> So this part appears more like NAG, but...
>>
>> ... something 

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Paul Richard Thomas via Fortran]

Hi Harald and Jerry,

I am reworking my way through, line by line wit F2018 in hand. Up to test
with offset 70, NAG looks to be right. I introduced an assignment with a
direct by ref function call, which doesn't finalise at the moment. Class
entities are yet to come. I'll report back early next week.

Thanks for all the help. I have (re)learned to read the standard very
carefully.

Best regards

Paul


On Fri, 11 Feb 2022, 21:08 Harald Anlauf,  wrote:

> Hi Paul,
>
> Am 11.02.22 um 10:08 schrieb Paul Richard Thomas via Fortran:
> > Your "stupid questions" are not at all stupid. The finalization of
> > 'variable' that occurs in your testcase demonstrates that the
> finalization
> > with my patch is occurring at the wrong time. I now see that NAG is
> correct
> > on this.
> >
> > Please press on with the questions!
>
> Jerry's suggestion to add lots of prints turned out to be really
> enlightening with regard to observable behavior.  I rewrote the
> testcase again and placed the interesting stuff into a subroutine.
> This way one can distinguish what actually happens during program
> start, entering and leaving a subroutine.
>
> I encountered the least surprises (= none) with NAG 7.0 here.
> For reference this is the output:
>
>   At start of program : 0
>
>   Enter sub   : 0
>   After 1st allocation: 0
>   After 2nd allocation: 0
>   Checking MyType% ind: 21
>   Checking MyType2%ind: 22
>   Deallocate MyType   : 0
>   # Leave desctructor1: 1 21
>   * MyType deallocated: 1
>   (kept MyType2 for automatic deallocation on return from sub)
>   Leave sub   : 1
>   # Leave desctructor1: 2 22
>
>   After sub   : 2
>
> To make it short: the destructor is called only when deallocation
> occurs, either explicitly or automatically.
>
>
> Intel 2021.5.0:
>
>   At start of program :   0
>
>   Enter sub   :   0
>   # Leave desctructor1:   1   0
>   After 1st allocation:   1
>   # Leave desctructor1:   2   0
>   After 2nd allocation:   2
>   Checking MyType% ind:  21
>   Checking MyType2%ind:  22
>   Deallocate MyType   :   2
>   # Leave desctructor1:   3  21
>   * MyType deallocated:   3
>   (kept MyType2 for automatic deallocation on return from sub)
>   Leave sub   :   3
>   # Leave desctructor1:   4  21
>   # Leave desctructor1:   5  22
>   # Leave desctructor1:   6  22
>
>   After sub   :   6
>
> So after entering the subroutine, the destructor is called twice,
> but for unknown reasons element ind, which I had expected to be
> either default-initialized to -1, or explicitly to 21 or 22, is 0.
> The places where this happens seem to be the assignments of
> MyType and MyType2.
>
> Furthermore, variable MyType is finalized on return from sub,
> although it is already deallocated, and MyType2 appears to
> get finalized twice automatically.
>
> I have no idea how this can get justified...
>
>
> Crayftn 12.0.2: in order to make the output easier to understand,
> I chose to reset final_count twice.  This will become clear soon.
>
>   # Leave desctructor1: 1,  20
>
>   At start of program : 1
>   +++ Resetting final_count for Cray Fortran : Version 12.0.2
>
>   # Leave desctructor1: 1,  21
>   # Leave desctructor1: 2,  22
>   Enter sub   : 2
>   +++ Resetting final_count for Cray Fortran : Version 12.0.2
>   After 1st allocation: 0
>   After 2nd allocation: 0
>   Checking MyType% ind: -21
>   Checking MyType2%ind: 22
>   Deallocate MyType   : 0
>   # Leave desctructor1: 1,  -21
>   * MyType deallocated: 1
>   (kept MyType2 for automatic deallocation on return from sub)
>   Leave sub   : 1
>   # Leave desctructor1: 2,  22
>
>   After sub   : 2
>
> So it appears that Cray is calling the destructor for each declaration
> where a constructor is involved, or the like.  Even if this is a
> parameter declaration, like in the main.  Resetting the counter for
> the first time.
>
> On entering sub, I see now two finalizations before the first print.
> Resetting the counter for the second time.
>
> But then the assignments do not invoke finalization, where Intel did.
> So this part appears more like NAG, but...
>
> ... something is strange here: component ind is wrong after the
> first assignment.  Looks clearly like a really bad bug.
>
> Explicit and automatic deallocation seems fine.
>
>
> Nvidia 22.2:
>
>   At start of program :0
>
>   Enter sub   :0
>   After 1st allocation:0
>   After 2nd allocation:0
>   Checking MyType% ind:   21
>   Checking MyType2%ind:   22
>   Deallocate MyType   :0
>   # Leave desctructor1:1   21
>   * MyType deallocated:1
>   (kept MyType2 for automatic deallocation on return from sub)
>   Leave sub   :1
>   # Leave 

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Harald Anlauf via Fortran]

Hi Paul,

Am 11.02.22 um 10:08 schrieb Paul Richard Thomas via Fortran:

Your "stupid questions" are not at all stupid. The finalization of
'variable' that occurs in your testcase demonstrates that the finalization
with my patch is occurring at the wrong time. I now see that NAG is correct
on this.

Please press on with the questions!


Jerry's suggestion to add lots of prints turned out to be really
enlightening with regard to observable behavior.  I rewrote the
testcase again and placed the interesting stuff into a subroutine.
This way one can distinguish what actually happens during program
start, entering and leaving a subroutine.

I encountered the least surprises (= none) with NAG 7.0 here.
For reference this is the output:

 At start of program : 0

 Enter sub   : 0
 After 1st allocation: 0
 After 2nd allocation: 0
 Checking MyType% ind: 21
 Checking MyType2%ind: 22
 Deallocate MyType   : 0
 # Leave desctructor1: 1 21
 * MyType deallocated: 1
 (kept MyType2 for automatic deallocation on return from sub)
 Leave sub   : 1
 # Leave desctructor1: 2 22

 After sub   : 2

To make it short: the destructor is called only when deallocation
occurs, either explicitly or automatically.


Intel 2021.5.0:

 At start of program :   0

 Enter sub   :   0
 # Leave desctructor1:   1   0
 After 1st allocation:   1
 # Leave desctructor1:   2   0
 After 2nd allocation:   2
 Checking MyType% ind:  21
 Checking MyType2%ind:  22
 Deallocate MyType   :   2
 # Leave desctructor1:   3  21
 * MyType deallocated:   3
 (kept MyType2 for automatic deallocation on return from sub)
 Leave sub   :   3
 # Leave desctructor1:   4  21
 # Leave desctructor1:   5  22
 # Leave desctructor1:   6  22

 After sub   :   6

So after entering the subroutine, the destructor is called twice,
but for unknown reasons element ind, which I had expected to be
either default-initialized to -1, or explicitly to 21 or 22, is 0.
The places where this happens seem to be the assignments of
MyType and MyType2.

Furthermore, variable MyType is finalized on return from sub,
although it is already deallocated, and MyType2 appears to
get finalized twice automatically.

I have no idea how this can get justified...


Crayftn 12.0.2: in order to make the output easier to understand,
I chose to reset final_count twice.  This will become clear soon.

 # Leave desctructor1: 1,  20

 At start of program : 1
 +++ Resetting final_count for Cray Fortran : Version 12.0.2

 # Leave desctructor1: 1,  21
 # Leave desctructor1: 2,  22
 Enter sub   : 2
 +++ Resetting final_count for Cray Fortran : Version 12.0.2
 After 1st allocation: 0
 After 2nd allocation: 0
 Checking MyType% ind: -21
 Checking MyType2%ind: 22
 Deallocate MyType   : 0
 # Leave desctructor1: 1,  -21
 * MyType deallocated: 1
 (kept MyType2 for automatic deallocation on return from sub)
 Leave sub   : 1
 # Leave desctructor1: 2,  22

 After sub   : 2

So it appears that Cray is calling the destructor for each declaration
where a constructor is involved, or the like.  Even if this is a
parameter declaration, like in the main.  Resetting the counter for
the first time.

On entering sub, I see now two finalizations before the first print.
Resetting the counter for the second time.

But then the assignments do not invoke finalization, where Intel did.
So this part appears more like NAG, but...

... something is strange here: component ind is wrong after the
first assignment.  Looks clearly like a really bad bug.

Explicit and automatic deallocation seems fine.


Nvidia 22.2:

 At start of program :0

 Enter sub   :0
 After 1st allocation:0
 After 2nd allocation:0
 Checking MyType% ind:   21
 Checking MyType2%ind:   22
 Deallocate MyType   :0
 # Leave desctructor1:1   21
 * MyType deallocated:1
 (kept MyType2 for automatic deallocation on return from sub)
 Leave sub   :1
 # Leave desctructor1:2   1590094384
 # Leave desctructor1:3   22

 After sub   :3

OK, that is really odd.  Although valgrind does not report
invalid accesses, there is something really fishy here.
I have not investigated further.  Nvidia is out for now.


One of the lessons learned is that it might be hard to write a
portable testcase that works for all compilers that rightfully(?)
can claim to implement finalization correctly...  And I have only
scratched the surface so far.

Paul: do you think you can enhance your much more comprehensive
testcase to ease debugging further?

Cheers,
Harald
module testmode
  implicit none

  type :: simple
 integer :: ind = -1
  contains
final :: destructor1
  end type simple

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Paul Richard Thomas via Fortran]

Hi Harald,

I have taken gcc-patches out of the loop for now :-)

I am really sorry to be such a bother, but before we think we should
> do the same as Intel, we need to understand what Intel does and whether
> that is actually correct.  Or not inconsistent with the standard.
> And I would really like to understand even the most simple, stupid case.
>

You are not being a bother. I am happy that you are taking an interest.

snip
>


> So my stupid questions are:
>
> - is ThyType invoking a constructor?  It is a parameter, after all.
>Should using it in an assignment invoke a destructor?  If so why?
>
>And why does Intel then increment the final_count?
>
> - is the initialization of ThyType2 invoking a constructor?
>It might, if that is the implementation in the compiler, but
>should there be a finalization?
>
>
7.5.6.3 When finalization occurs
1 When an intrinsic assignment statement is executed (10.2.1.3), if the
variable is not an unallocated allocatable
variable, it is finalized after evaluation of expr and before the
definition of the variable. If the variable is an
allocated allocatable variable, or has an allocated allocatable subobject,
that would be deallocated by intrinsic
assignment, the finalization occurs before the deallocation.

Your "stupid questions" are not at all stupid. The finalization of
'variable' that occurs in your testcase demonstrates that the finalization
with my patch is occurring at the wrong time. I now see that NAG is correct
on this.

Please press on with the questions!

Regards

Paul

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Jerry D via Fortran]

For what it is worth.

On 2/10/22 11:49 AM, Harald Anlauf via Fortran wrote:

Hi Paul,

Am 10.02.22 um 13:25 schrieb Paul Richard Thomas via Fortran:

Conclusions on ifort:
(i) The agreement between gfortran, with the patch applied, and ifort is
strongest of all the other brands;
(ii) The disagreements are all down to the treatment of the parent
component of arrays of extended types: gfortran finalizes the parent
component as an array, whereas ifort does a scalarization. I have a 
patch

ready to do likewise.

Overall conclusions:
(i) Sort out whether or not derived type constructors are considered 
to be

functions;
(ii) Come to a conclusion about scalarization of parent components of
extended type arrays;
(iii) Check and, if necessary, correct the ordering of finalization in
intrinsic assignment of class arrays.
(iv) Finalization is difficult to graft on to existing pre-F2003 
compilers,

as witnessed by the range of implementations.

I would be really grateful for thoughts on (i) and (ii). My gut 
feeling, as

remarked in the submission, is that we should aim to be as close as
possible, if not identical to, ifort. Happily, that is already the case.


I am really sorry to be such a bother, but before we think we should
do the same as Intel, we need to understand what Intel does and whether
that is actually correct.  Or not inconsistent with the standard.
And I would really like to understand even the most simple, stupid case.

I did reduce testcase finalize_38.f90 to an almost bare minimum,
see attached, and changed the main to

  type(simple), parameter   :: ThyType   = simple(21)
  type(simple)  :: ThyType2  = simple(22)
  type(simple), allocatable :: MyType, MyType2

  print *, "At start of program: ", final_count

  MyType = ThyType
  print *, "After 1st allocation:", final_count

  MyType2 = ThyType2
  print *, "After 2nd allocation:", final_count

Note that "ThyType" is now a parameter.


- snip 
Ignore whether Thytype is  a Parameter.  Regardless Mytype and Mytype2 
are allocated upon the assignment.  Now if these are never used 
anywhere, it seems to me the deallocation can be done by the compiler 
anywhere after the last time it is used.  So it can be either after the 
PRINT statement before the end if the program or right after the 
assignment before your PRINT statements that examine the value of 
final_count.  I think the result is arbitrary/undefined in your reduced 
test case


I do not have the Intel compiler yet, so I was going to suggest see what 
it does if your test program prints something from within MyType and 
MyType2 after all your current print statements at the end.  Try this 
variation of the main program.


program test_final
  use testmode
  implicit none
  type(simple), parameter   :: ThyType   = simple(21)
  type(simple)  :: ThyType2  = simple(22)
  type(simple), allocatable :: MyType, MyType2

  print *, "At start of program: ", final_count

  MyType = ThyType
  print *, "After 1st allocation:", final_count

  MyType2 = ThyType2
  print *, "After 2nd allocation:", final_count

  print  *, MyType%ind, MyType2%ind, final_count
  deallocate(Mytype)
  print  *, MyType%ind, MyType2%ind, final_count
  deallocate(Mytype2)
  print  *, MyType%ind, MyType2%ind, final_count

end program test_final

I get with trunk:

$ ./a.out
 At start of program:    0
 After 1st allocation:    0
 After 2nd allocation:   0
  21 22   0
   0  22   1
   0  0 2

Which makes sense to me.

Regards,

Jerry

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Harald Anlauf via Fortran]

Hi Paul,

Am 10.02.22 um 13:25 schrieb Paul Richard Thomas via Fortran:

Conclusions on ifort:
(i) The agreement between gfortran, with the patch applied, and ifort is
strongest of all the other brands;
(ii) The disagreements are all down to the treatment of the parent
component of arrays of extended types: gfortran finalizes the parent
component as an array, whereas ifort does a scalarization. I have a patch
ready to do likewise.

Overall conclusions:
(i) Sort out whether or not derived type constructors are considered to be
functions;
(ii) Come to a conclusion about scalarization of parent components of
extended type arrays;
(iii) Check and, if necessary, correct the ordering of finalization in
intrinsic assignment of class arrays.
(iv) Finalization is difficult to graft on to existing pre-F2003 compilers,
as witnessed by the range of implementations.

I would be really grateful for thoughts on (i) and (ii). My gut feeling, as
remarked in the submission, is that we should aim to be as close as
possible, if not identical to, ifort. Happily, that is already the case.


I am really sorry to be such a bother, but before we think we should
do the same as Intel, we need to understand what Intel does and whether
that is actually correct.  Or not inconsistent with the standard.
And I would really like to understand even the most simple, stupid case.

I did reduce testcase finalize_38.f90 to an almost bare minimum,
see attached, and changed the main to

  type(simple), parameter   :: ThyType   = simple(21)
  type(simple)  :: ThyType2  = simple(22)
  type(simple), allocatable :: MyType, MyType2

  print *, "At start of program: ", final_count

  MyType = ThyType
  print *, "After 1st allocation:", final_count

  MyType2 = ThyType2
  print *, "After 2nd allocation:", final_count

Note that "ThyType" is now a parameter.

I tested the above and found:

Intel:
 At start of program:0
 After 1st allocation:   1
 After 2nd allocation:   2

NAG 7.0:
 At start of program:  0
 After 1st allocation: 0
 After 2nd allocation: 0

Crayftn 12.0.2:
 At start of program:  2
 After 1st allocation: 2
 After 2nd allocation: 2

Nvidia 22.1:
 At start of program: 0
 After 1st allocation:0
 After 2nd allocation:0

So my stupid questions are:

- is ThyType invoking a constructor?  It is a parameter, after all.
  Should using it in an assignment invoke a destructor?  If so why?

  And why does Intel then increment the final_count?

- is the initialization of ThyType2 invoking a constructor?
  It might, if that is the implementation in the compiler, but
  should there be a finalization?

  Then ThyType2 is used in an intrinsic assignment, basically the
  same as the other one before.  Now what is the difference?

Are all compilers correct, but I do not see it?

Someone please help!


Best regards

Paul



Cheers,
Harald
module testmode
  implicit none

  type :: simple
 integer :: ind
  contains
final :: destructor1
  end type simple

  integer :: final_count = 0

contains

  subroutine destructor1(self)
type(simple), intent(inout) :: self
final_count = final_count + 1
  end subroutine destructor1

end module testmode

program test_final
  use testmode
  implicit none
  type(simple), parameter   :: ThyType   = simple(21)
  type(simple)  :: ThyType2  = simple(22)
  type(simple), allocatable :: MyType, MyType2

  print *, "At start of program: ", final_count

  MyType = ThyType
  print *, "After 1st allocation:", final_count

  MyType2 = ThyType2
  print *, "After 2nd allocation:", final_count

end program test_final

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Paul Richard Thomas via Fortran]

Hi Harald,


I have run your modified version of finalize_38.f90, and now I see
> that you can get a bloody head just from scratching too much...
>
> crayftn 12.0.2:
>
>   1,  3,  1
>
 It appears that Cray interpret a derived type constructor as being a
function call and so "6 If a specification expression in a scoping unit
references a function, the result is finalized before execution of the
executable constructs in the scoping unit."
A call to 'test' as the first statement might be useful to diagnose: call
test(2, 0, [0,0], -10)

>   2,  21,  0
>
21 is presumably the value left over from simple(21) but quite why it
should happen in this order is not apparent to me.

>   11,  3,  2
>
I am mystified as to why the finalization of 'var' is not occurring because
"1 When an intrinsic assignment statement is executed (10.2.1.3), if the
variable is not an unallocated allocatable variable, it is finalized after
evaluation of expr and before the definition of the variable." Note the
double negative! 'var' has been allocated and should return 1 to 'scalar'

>   12,  21,  1
>   21,  4,  3
>
This is a residue of earlier differences in the final count.

>   23,  21,  22 | 42,  43
>
The value is inexplicable to me.

  31,  6,  4
>   41,  7,  5
>   51,  9,  7
>   61,  10,  8
>   71,  13,  10
>   101,  2,  1
>
One again, a function 'expr' finalization has been added after intrinsic
assignment; ie. derived type constructor == function.

>   102,  4,  3
>


>   111,  3,  2
>   121,  4,  2
>   122,  0,  4
>   123,  5,  6 | 2*0
>
>From the value of 'array', I would devine that the source in the allocation
is being finalized as an array, whereas I would expect each invocation of
'simple' to generate a scalar final call.

>   131,  5,  2
>   132,  0,  4
>   133,  7,  8 | 2*0
>
The final count has increased by 1, as expected.  The value of 'scalar' is
stuck at 0, so the second line is explicable. The array value is explicable
if the finalization is of 'expr' and that 'var' is not finalized or the
finalization of 'var' is occuring after assignment; ie. wrong order.
***I notice from the code that even with the patch, gfortran is finalizing
before evaluation of 'expr', which is incorrect. It should be after
evaluation of 'expr' and before the assignment.***

  141,  6,  3
>
Final count offset - OK

  151,  10,  5
>
The two extra calls come, I presume from the source in the allocation.
Since the type is extended, we see two finalizations each for the
allocation and the deallocation.

  161,  16,  9
>
 I think that the extra two finalizations come from the evaluation of 'src'
in 'constructor2'.

  171,  18,  11
>
Final count offset - OK

  175,  0.,  20. | 10.,  20.
>
The value of 'rarray' is mystifying.

Conclusions from Cray:
(i) Determine if derived type constructors should be interpreted as
function calls.
(ii) The order of finalization in class array assignment needs to be
checked and fixed if necessary.

>
> nagfor 7.0:
>
>   1 0 1
>
"1 When an intrinsic assignment statement is executed (10.2.1.3), if the
variable is not an unallocated allocatable variable, it is finalized after
evaluation of expr and before the definition of the variable."   So I think
that NAG has this wrong, either because the timing is right and an
unallocatable allocatable is being finalized or because the timing is wrong.

  11 1 2
>   23 21 22 | 42 43
>
It seems that the finalization is occurring after assignment.

  71 9 10
>   72 11 99
>
It seems that the finalization of the function 'expr' after assignment is
not happening.

  131 3 2
>   132 5 4
>
I am not sure that I know where the extra final call is nor where the
scalar value of 5 comes from.

  141 4 3
>   151 6 5
>   161 10 9
>   171 12 11
>
 The above are OK since there is an offset in the final count, starting at
131.

Conclusions from NAG:
(i) Some minor nits but pretty close to my interpretation.


Intel 2021.5.0:
>
>   131   3   2
>   132   0   4
>   133   5   6 |   0   0
>   141   4   3
>   151   7   5
>   152   3   0
>   153   0   0 |   1   3
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
> [...]
>

ifort (IFORT) 2021.1 Beta 20201112 manages to carry on to the end.
 161  13   9
 162  20   0
 163   0   0 |  10  20
 171  14  11

Conclusions on ifort:
(i) The agreement between gfortran, with the patch applied, and ifort is
strongest of all the other brands;
(ii) The disagreements are all down to the treatment of the parent
component of arrays of extended types: gfortran finalizes the parent
component as an array, whereas ifort does a scalarization. I have a patch
ready to do likewise.

Overall conclusions:
(i) Sort out whether or not derived type constructors are 

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Jerry D via Fortran]

Remember the days when reading very old cryptic Fortran code? Remember 
the fixed line lengths and cryptic variable names!


I fear the Standards committee has achieved history with the Standard 
itself it is so difficult to understand sometimes.


Cheers to Paul and Harald for digging on this.

Jerry

On 2/8/22 11:29 AM, Harald Anlauf via Fortran wrote:

Hi Paul,

Am 08.02.22 um 12:22 schrieb Paul Richard Thomas via Fortran:

Hi Harald,

Thanks for giving the patch a whirl.


the parent components as an array. I strongly suspect that, from 
reading

7.5.6.2 paragraphs 2 and 3 closely, that ifort has it right. However,

this

is another issue to come back to in the future.


Could you specify which version of Intel you tried?



ifort (IFORT) 2021.1 Beta 20201112


ok, that's good to know.



Testcase finalize_38.f90 fails for me with ifort 2021.5.0 with:

131

This test also fails with crayftn 11 & 12 and nagfor 7.0,
but in a different place.



I have run your modified version of finalize_38.f90, and now I see
that you can get a bloody head just from scratching too much...

crayftn 12.0.2:

 1,  3,  1
 2,  21,  0
 11,  3,  2
 12,  21,  1
 21,  4,  3
 23,  21,  22 | 42,  43
 31,  6,  4
 41,  7,  5
 51,  9,  7
 61,  10,  8
 71,  13,  10
 101,  2,  1
 102,  4,  3
 111,  3,  2
 121,  4,  2
 122,  0,  4
 123,  5,  6 | 2*0
 131,  5,  2
 132,  0,  4
 133,  7,  8 | 2*0
 141,  6,  3
 151,  10,  5
 161,  16,  9
 171,  18,  11
 175,  0.,  20. | 10.,  20.

nagfor 7.0:

 1 0 1
 11 1 2
 23 21 22 | 42 43
 71 9 10
 72 11 99
 131 3 2
 132 5 4
 141 4 3
 151 6 5
 161 10 9
 171 12 11

Intel 2021.5.0:

 131   3   2
 132   0   4
 133   5   6 |   0   0
 141   4   3
 151   7   5
 152   3   0
 153   0   0 |   1   3
forrtl: severe (174): SIGSEGV, segmentation fault occurred
[...]


That got me reading 7.5.6.3, where is says in paragraph 1:

"When an intrinsic assignment statement is executed (10.2.1.3), if the
variable is not an unallocated allocatable variable, it is finalized
after evaluation of expr and before the definition of the variable.
..."

Looking at the beginning of the testcase code (abridged):

  type(simple), allocatable :: MyType, MyType2
  type(simple) :: ThyType = simple(21), ThyType2 = simple(22)

! The original PR - one finalization of 'var' before (re)allocation.
  MyType = ThyType
  call test(1, 0, [0,0], 0)


This is an intrinsic assignment.

Naively I would expect MyType to be initially unallocated.

ThyType is not allocatable and non-pointer and cannot become
undefined here and would not play any role in finalization.

I am probably too blind-sighted to see why there should be
a finalization here.  What am I missing?

Could you use the attached version of finalize_38.f90 with crayftn 
and NAG?

All the stop statements are replaced with prints. Ifort gives:
  131   3   2
  132   0   4
  133   5   6 |   0   0
  141   4   3
  151   7   5
  152   3   0
  153   0   0 |   1   3
  161  13   9
  162  20   0
  163   0   0 |  10  20
  171  14  11


I think it is a good idea to have these prints in the testcase
whenever there is a departure from expectations.  So print?

Furthermore, for the sake of health of people reading the testcases
later, I think it would not harm to add more explanations why we
expect a certain behavior... ;-)


Best regards

Paul


Best regards,
Harald

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Harald Anlauf via Fortran]

Hi Paul,

Am 08.02.22 um 12:22 schrieb Paul Richard Thomas via Fortran:

Hi Harald,

Thanks for giving the patch a whirl.



the parent components as an array. I strongly suspect that, from reading

7.5.6.2 paragraphs 2 and 3 closely, that ifort has it right. However,

this

is another issue to come back to in the future.


Could you specify which version of Intel you tried?



ifort (IFORT) 2021.1 Beta 20201112


ok, that's good to know.



Testcase finalize_38.f90 fails for me with ifort 2021.5.0 with:

131

This test also fails with crayftn 11 & 12 and nagfor 7.0,
but in a different place.



I have run your modified version of finalize_38.f90, and now I see
that you can get a bloody head just from scratching too much...

crayftn 12.0.2:

 1,  3,  1
 2,  21,  0
 11,  3,  2
 12,  21,  1
 21,  4,  3
 23,  21,  22 | 42,  43
 31,  6,  4
 41,  7,  5
 51,  9,  7
 61,  10,  8
 71,  13,  10
 101,  2,  1
 102,  4,  3
 111,  3,  2
 121,  4,  2
 122,  0,  4
 123,  5,  6 | 2*0
 131,  5,  2
 132,  0,  4
 133,  7,  8 | 2*0
 141,  6,  3
 151,  10,  5
 161,  16,  9
 171,  18,  11
 175,  0.,  20. | 10.,  20.

nagfor 7.0:

 1 0 1
 11 1 2
 23 21 22 | 42 43
 71 9 10
 72 11 99
 131 3 2
 132 5 4
 141 4 3
 151 6 5
 161 10 9
 171 12 11

Intel 2021.5.0:

 131   3   2
 132   0   4
 133   5   6 |   0   0
 141   4   3
 151   7   5
 152   3   0
 153   0   0 |   1   3
forrtl: severe (174): SIGSEGV, segmentation fault occurred
[...]


That got me reading 7.5.6.3, where is says in paragraph 1:

"When an intrinsic assignment statement is executed (10.2.1.3), if the
variable is not an unallocated allocatable variable, it is finalized
after evaluation of expr and before the definition of the variable.
..."

Looking at the beginning of the testcase code (abridged):

  type(simple), allocatable :: MyType, MyType2
  type(simple) :: ThyType = simple(21), ThyType2 = simple(22)

! The original PR - one finalization of 'var' before (re)allocation.
  MyType = ThyType
  call test(1, 0, [0,0], 0)


This is an intrinsic assignment.

Naively I would expect MyType to be initially unallocated.

ThyType is not allocatable and non-pointer and cannot become
undefined here and would not play any role in finalization.

I am probably too blind-sighted to see why there should be
a finalization here.  What am I missing?


Could you use the attached version of finalize_38.f90 with crayftn and NAG?
All the stop statements are replaced with prints. Ifort gives:
  131   3   2
  132   0   4
  133   5   6 |   0   0
  141   4   3
  151   7   5
  152   3   0
  153   0   0 |   1   3
  161  13   9
  162  20   0
  163   0   0 |  10  20
  171  14  11


I think it is a good idea to have these prints in the testcase
whenever there is a departure from expectations.  So print?

Furthermore, for the sake of health of people reading the testcases
later, I think it would not harm to add more explanations why we
expect a certain behavior... ;-)


Best regards

Paul


Best regards,
Harald

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Paul Richard Thomas via Fortran]

Hi Harald,

Thanks for giving the patch a whirl.


> the parent components as an array. I strongly suspect that, from reading
> > 7.5.6.2 paragraphs 2 and 3 closely, that ifort has it right. However,
> this
> > is another issue to come back to in the future.
>
> Could you specify which version of Intel you tried?
>

ifort (IFORT) 2021.1 Beta 20201112

>
> Testcase finalize_38.f90 fails for me with ifort 2021.5.0 with:
>
> 131
>

That's the point where the interpretation of the standard diverges. Ifort
uses the scalar finalization for the parent component, whereas gfortran
uses the rank 1. Thus the final count is different by one. I have a version
of the patch, where gfortran behaves in the same way as ifort.


> This test also fails with crayftn 11 & 12 and nagfor 7.0,
> but in a different place.
>



>
> (Also finalize_45.f90 fails with that version with something that
> looks like memory corruption, but that might be just a compiler bug.)
>

I take it 'that version' is of ifort? Mine does the same. I suspect that it
is one of the perils of using pointer components in such circumstances! You
will notice that I had to nullify pointer components when doing the copy.

>
> Thanks,
> Harald
>

Could you use the attached version of finalize_38.f90 with crayftn and NAG?
All the stop statements are replaced with prints. Ifort gives:
 131   3   2
 132   0   4
 133   5   6 |   0   0
 141   4   3
 151   7   5
 152   3   0
 153   0   0 |   1   3
 161  13   9
 162  20   0
 163   0   0 |  10  20
 171  14  11

Best regards

Paul
! { dg-do run }
!
! Test finalization on intrinsic assignment (F2018 (7.5.6.3))
!
module testmode
  implicit none

  type :: simple
integer :: ind
  contains
final :: destructor1, destructor2
  end type simple

  type, extends(simple) :: complicated
real :: rind
  contains
final :: destructor3, destructor4
  end type complicated

  integer :: check_scalar
  integer :: check_array(4)
  real :: check_real
  real :: check_rarray(4)
  integer :: final_count = 0

contains

  subroutine destructor1(self)
type(simple), intent(inout) :: self
check_scalar = self%ind
check_array = 0
final_count = final_count + 1
  end subroutine destructor1

  subroutine destructor2(self)
type(simple), intent(inout) :: self(:)
check_scalar = 0
check_array(1:size(self, 1)) = self%ind
final_count = final_count + 1
  end subroutine destructor2

  subroutine destructor3(self)
type(complicated), intent(inout) :: self
check_real = self%rind
check_array = 0.0
final_count = final_count + 1
  end subroutine destructor3

  subroutine destructor4(self)
type(complicated), intent(inout) :: self(:)
check_real = 0.0
check_rarray(1:size(self, 1)) = self%rind
final_count = final_count + 1
  end subroutine destructor4

  function constructor1(ind) result(res)
type(simple), allocatable :: res
integer, intent(in) :: ind
allocate (res, source = simple (ind))
  end function constructor1

  function constructor2(ind, rind) result(res)
class(simple), allocatable :: res(:)
integer, intent(in) :: ind(:)
real, intent(in), optional :: rind(:)
type(complicated), allocatable :: src(:)
integer :: sz
integer :: i
if (present (rind)) then
  sz = min (size (ind, 1), size (rind, 1))
  src  = [(complicated (ind(i), rind(i)), i = 1, sz)]
  allocate (res, source = src)
else
  sz = size (ind, 1)
  allocate (res, source = [(simple (ind(i)), i = 1, sz)])
end if
  end function constructor2

  subroutine test (cnt, scalar, array, off, rind, rarray)
integer :: cnt
integer :: scalar
integer :: array(:)
integer :: off
real, optional :: rind
real, optional :: rarray(:)
if (final_count .ne. cnt)  print *, 1 + off, final_count, cnt
if (check_scalar .ne. scalar) print *, 2 + off, check_scalar, scalar
if (any (check_array(1:size (array, 1)) .ne. array)) print *,  3 + off, &
   check_array(1:size (array, 1)), "|", array
if (present (rind)) then
  if (check_real .ne. rind)  print *,  4+off, check_real, rind
end if
if (present (rarray)) then
  if (any (check_rarray(1:size (rarray, 1)) .ne. rarray)) print *,  5 + off, &
   check_rarray(1:size (rarray, 1)), "|", rarray
end if
  end subroutine test

end module testmode

program test_final
  use testmode
  implicit none

  type(simple), allocatable :: MyType, MyType2
  type(simple), allocatable :: MyTypeArray(:)
  type(simple) :: ThyType = simple(21), ThyType2 = simple(22)
  class(simple), allocatable :: MyClass
  class(simple), allocatable :: 

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Harald Anlauf via Fortran]

Hi Paul,

thanks for attacking this.

I haven't looked at the actual patch, only tried to check the new
testcases with other compilers.

Am 03.02.22 um 18:14 schrieb Paul Richard Thomas via Fortran:

I have tried to interpret F2018 7.5.6.2 and 7.5.6.3 as well as possible.
This is not always straightforward and has involved a lot of head
scratching! I have used the Intel compiler as a litmus test for the
outcomes. This was largely motivated by the observation that, in the user
survey conducted by Steve Lionel, gfortran and ifort are often used
together . Therefore, quite aside from wishing to comply with the standard
as far as possible, it is more than reasonable that the two compilers
comply. On application of this patch, only exception to this is the
treatment of finalization of arrays of extended types, where the Intel
takes "If the entity is of extended type and the parent type is
finalizable, the parent component is finalized" such that the parent
component is finalized one element at a time, whereas gfortran finalises
the parent components as an array. I strongly suspect that, from reading
7.5.6.2 paragraphs 2 and 3 closely, that ifort has it right. However, this
is another issue to come back to in the future.


Could you specify which version of Intel you tried?

Testcase finalize_38.f90 fails for me with ifort 2021.5.0 with:

131

This test also fails with crayftn 11 & 12 and nagfor 7.0,
but in a different place.

(Also finalize_45.f90 fails with that version with something that
looks like memory corruption, but that might be just a compiler bug.)

Thanks,
Harald

[Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Paul Richard Thomas via Fortran]

This patch has been an excessively long time in coming. Please accept my
apologies for that.

All but two of the PR37336 dependencies are fixed, The two exceptions are
PRs 59694 and 65347. The former involves lack of finalization of an
unreferenced entity declared in a block, which I am sure is trivial but I
cannot see where the missing trigger is, and the latter involves
finalization of function results within an array constructor, for which I
will submit an additional patch shortly.  PR104272 also remains, in which
finalization is occurring during allocation. I fixed this in one place but
it seems to have crept out in another :-)

Beyond this patch and ones for the three lagging PRs above, a thorough tidy
up and unification of finalization is needed. However, I will concentrate
on functionality in the first instance.

I have tried to interpret F2018 7.5.6.2 and 7.5.6.3 as well as possible.
This is not always straightforward and has involved a lot of head
scratching! I have used the Intel compiler as a litmus test for the
outcomes. This was largely motivated by the observation that, in the user
survey conducted by Steve Lionel, gfortran and ifort are often used
together . Therefore, quite aside from wishing to comply with the standard
as far as possible, it is more than reasonable that the two compilers
comply. On application of this patch, only exception to this is the
treatment of finalization of arrays of extended types, where the Intel
takes "If the entity is of extended type and the parent type is
finalizable, the parent component is finalized" such that the parent
component is finalized one element at a time, whereas gfortran finalises
the parent components as an array. I strongly suspect that, from reading
7.5.6.2 paragraphs 2 and 3 closely, that ifort has it right. However, this
is another issue to come back to in the future.

The work centred on three areas:
(i) Finalization on assignment:
This was required because finalization of the lhs was occurring at the
wrong time relative to evaluation of the rhs expression and was taking the
finalization of entities with finalizable components in the wrong order.
The changes in trans-array.cc (structure_alloc_comps) allow
gfc_deallocate_alloc_comp_no_caf to occur without finalization so that it
can be preceded by calls to the finalization wrapper. The other key change
in this area is the addition of trans-expr.cc
(gfc_assignment_finalizer_call), which manages the ordering of finalization
and deallocation.

(ii) Finalization of derived type function results.
Previously, finalization was not occuring at all for derived type results
but it did for class results. The former is now implemented in
trans-expr.cc (finalize_function_result), into which the treatment of class
finalization has been included. In order to handled complex expressions
correctly, an extra block has been included in gfc_se and is initialized in
gfc_init_se. This block accumulates the finalizations so that they can be
added at the right time. It is the way in which I will fix PR65347 (I have
already tested the principle).

(iii) Minor fixes
These include the changes in class.cc and the exclusion of artificial
entities from finalization.

There are some missing testcases (sorry Andrew and Sandro!), which might
not be necessary because the broken/missing features are already fixed. The
fact that the work correctly now is a strong indication that this is the
case.

Regtests OK on FC33/x86_64 - OK for mainline (and 11-branch)?

Best regards

Paul

Fortran:Implement missing finalization features [PR37336]

2022-02-02  Paul Thomas  

gcc/fortran
PR fortran/103854
* class.cc (has_finalizer_component): Do not return true for
procedure pointer components.

PR fortran/96122
* class.cc (finalize_component): Include the missing arguments
in the call to the component's finalizer wrapper.

PR fortran/37336
* class.cc (finalizer_insert_packed_call): Remove the redundant
argument in the call to the final subroutine.
* resolve.cc (resolve_where, gfc_resolve_where_code_in_forall,
gfc_resolve_forall_body, gfc_resolve_code): Check that the op
code is still EXEC_ASSIGN. If it is set lhs to must finalize.
* trans-array.cc (structure_alloc_comps): Add boolean argument
to suppress finalization and use it for calls from
gfc_deallocate_alloc_comp_no_caf. Otherwise it defaults to
false. Add a second, additional boolean argument to nullify
pointer components and use it in gfc_copy_alloc_comp_del_ptrs.
(gfc_alloc_allocatable_for_assignment): Suppress finalization
by setting new arg in call to gfc_deallocate_alloc_comp_no_caf.
(gfc_copy_alloc_comp_del_ptrs): New function.
* trans-array.h : Add the new boolean argument to the prototype
of gfc_deallocate_alloc_comp_no_caf with a default of false.
Add prototype for gfc_copy_alloc_comp_del_ptrs.
* trans-expr.cc (gfc_init_se): Initialize finalblock.
(finalize_function_result): New function that finalizes
function results in the correct order.
(gfc_conv_procedure_call): Use