finalization issue

finalization issue

[Steve Kargl]

All,

PR97122 shows an issue with finalization.
It seems I attached a diff to the PR in 2020,
which allows the code to compile.  The diff
applied to today's trunk still allows the
code to compile but there is now at least
1 regression with finalize_8.f03.

Even with my patch, I'm uncertain as to 
whether the finalizing subroutine is 
correctly hooked to the right namespace.

-- 
steve

Re: finalization issue

[Paul Richard Thomas]

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

Hi Steve,

Nagfor responds to the test case with "Error: pr97122.f90, line 14: Type T
has final subroutines but is not defined in the specification part of a
module"

F2018:
"C787(R753) A final-subroutine-name shall be the name of a module procedure
with exactly one dummy argument."

Since, of necessity, the argument is declared to be of the derived type
with the final binding, the gfortran and nagfor errors are correct IMHO.
ifort compiles it without complaint.

I have marked this as "waiting" pending a contrary interpretation.

Cheers

Paul

On Wed, 3 May 2023 at 23:59, Steve Kargl via Fortran <fortran@gcc.gnu.org>
wrote:

> All,
>
> PR97122 shows an issue with finalization.
> It seems I attached a diff to the PR in 2020,
> which allows the code to compile.  The diff
> applied to today's trunk still allows the
> code to compile but there is now at least
> 1 regression with finalize_8.f03.
>
> Even with my patch, I'm uncertain as to
> whether the finalizing subroutine is
> correctly hooked to the right namespace.
>
> --
> steve
>


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

Re: finalization issue

[Steve Kargl]

Hi Paul,

I'll need to go through F2018 again, but I thought
I found a statement that a module procedure can be 
in a submodule.  Here's the starting point

   14.2.3 Submodules

   A submodule is a program unit that extends a module or another
   submodule.
   ...
   A submodule may provide implementations for separate module
   procedures (15.6.2.5), each of which is declared (15.4.3.2)
   within that submodule or one of its ancestors, and declarations
   and definitions of other entities that are accessible by host
   association in its descendants.

   15.2.2.2 External, internal, and module procedures
   ...
   A module procedure is a procedure that is defined by a
   module subprogram,

   15.6.2 Procedures defined by subprograms
   ...
   C1548 (R1526) If MODULE appears in the prefix of a module
   subprogram, it shall have been declared to be a separate
   module procedure in the containing program unit or an ancestor 
   of that program unit.

At this point, I get bogged down in chase 'module subprogram'
through the standard.


On Thu, May 04, 2023 at 09:09:30AM +0100, Paul Richard Thomas wrote:
> Hi Steve,
> 
> Nagfor responds to the test case with "Error: pr97122.f90, line 14: Type T
> has final subroutines but is not defined in the specification part of a
> module"
> 
> F2018:
> "C787(R753) A final-subroutine-name shall be the name of a module procedure
> with exactly one dummy argument."
> 
> Since, of necessity, the argument is declared to be of the derived type
> with the final binding, the gfortran and nagfor errors are correct IMHO.
> ifort compiles it without complaint.
> 
> I have marked this as "waiting" pending a contrary interpretation.
> 
> Cheers
> 
> Paul
> 
> On Wed, 3 May 2023 at 23:59, Steve Kargl via Fortran <fortran@gcc.gnu.org>
> wrote:
> 
> > All,
> >
> > PR97122 shows an issue with finalization.
> > It seems I attached a diff to the PR in 2020,
> > which allows the code to compile.  The diff
> > applied to today's trunk still allows the
> > code to compile but there is now at least
> > 1 regression with finalize_8.f03.
> >
> > Even with my patch, I'm uncertain as to
> > whether the finalizing subroutine is
> > correctly hooked to the right namespace.
> >
> > --
> > steve
> >
> 
> 
> -- 
> "If you can't explain it simply, you don't understand it well enough" -
> Albert Einstein

-- 
Steve