* finalization issue
@ 2023-05-03 22:58 Steve Kargl
2023-05-04 8:09 ` Paul Richard Thomas
0 siblings, 1 reply; 3+ messages in thread
From: Steve Kargl @ 2023-05-03 22:58 UTC (permalink / raw)
To: fortran
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: finalization issue
2023-05-03 22:58 finalization issue Steve Kargl
@ 2023-05-04 8:09 ` Paul Richard Thomas
2023-05-04 14:44 ` Steve Kargl
0 siblings, 1 reply; 3+ messages in thread
From: Paul Richard Thomas @ 2023-05-04 8:09 UTC (permalink / raw)
To: sgk; +Cc: fortran
[-- 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: finalization issue
2023-05-04 8:09 ` Paul Richard Thomas
@ 2023-05-04 14:44 ` Steve Kargl
0 siblings, 0 replies; 3+ messages in thread
From: Steve Kargl @ 2023-05-04 14:44 UTC (permalink / raw)
To: Paul Richard Thomas; +Cc: fortran
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-05-04 14:44 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-03 22:58 finalization issue Steve Kargl
2023-05-04 8:09 ` Paul Richard Thomas
2023-05-04 14:44 ` Steve Kargl
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).