* [Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
2020-09-20 0:21 [Bug fortran/97122] New: Spurious FINAL ... must be in the specification part of a MODULE ian_harvey at bigpond dot com
@ 2020-09-20 3:26 ` kargl at gcc dot gnu.org
2023-05-04 6:13 ` pault at gcc dot gnu.org
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: kargl at gcc dot gnu.org @ 2020-09-20 3:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2020-09-20
Ever confirmed|0 |1
CC| |kargl at gcc dot gnu.org
Priority|P3 |P4
Status|UNCONFIRMED |NEW
--- Comment #1 from kargl at gcc dot gnu.org ---
This allows your code to compile.
Index: gcc/fortran/decl.c
===================================================================
--- gcc/fortran/decl.c (revision 280157)
+++ gcc/fortran/decl.c (working copy)
@@ -11395,8 +11395,9 @@ gfc_match_final_decl (void)
block = gfc_state_stack->previous->sym;
gcc_assert (block);
- if (!gfc_state_stack->previous || !gfc_state_stack->previous->previous
- || gfc_state_stack->previous->previous->state != COMP_MODULE)
+ if (!gfc_state_stack->previous->previous
+ && gfc_state_stack->previous->previous->state != COMP_MODULE
+ && gfc_state_stack->previous->previous->state != COMP_SUBMODULE)
{
gfc_error ("Derived type declaration with FINAL at %C must be in the"
" specification part of a MODULE");
Alternatively, the if-block can likely be removed.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
2020-09-20 0:21 [Bug fortran/97122] New: Spurious FINAL ... must be in the specification part of a MODULE ian_harvey at bigpond dot com
2020-09-20 3:26 ` [Bug fortran/97122] " kargl at gcc dot gnu.org
@ 2023-05-04 6:13 ` pault at gcc dot gnu.org
2023-05-04 8:07 ` pault at gcc dot gnu.org
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: pault at gcc dot gnu.org @ 2023-05-04 6:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pault at gcc dot gnu.org
Blocks| |37336
--- Comment #2 from Paul Thomas <pault at gcc dot gnu.org> ---
Setting this PR as blocking PR37336.
Thanks for pointing it out, Steve.
I think that your patch does the right thing. I will investigate the
regression.
Cheers
Paul
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug 37336] [F03] Finish derived-type finalization
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
2020-09-20 0:21 [Bug fortran/97122] New: Spurious FINAL ... must be in the specification part of a MODULE ian_harvey at bigpond dot com
2020-09-20 3:26 ` [Bug fortran/97122] " kargl at gcc dot gnu.org
2023-05-04 6:13 ` pault at gcc dot gnu.org
@ 2023-05-04 8:07 ` pault at gcc dot gnu.org
2023-05-04 17:45 ` kargl at gcc dot gnu.org
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: pault at gcc dot gnu.org @ 2023-05-04 8:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
--- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
2020-09-20 0:21 [Bug fortran/97122] New: Spurious FINAL ... must be in the specification part of a MODULE ian_harvey at bigpond dot com
` (2 preceding siblings ...)
2023-05-04 8:07 ` pault at gcc dot gnu.org
@ 2023-05-04 17:45 ` kargl at gcc dot gnu.org
2023-05-04 19:01 ` kargl at gcc dot gnu.org
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: kargl at gcc dot gnu.org @ 2023-05-04 17:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #3)
> 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
Hi Paul,
I don't see how C787 applies.
SUBROUTINE p(arg)
TYPE(t), INTENT(INOUT) :: arg
END SUBROUTINE p
p() has exactly one argument. If I read F2018 correctly (which is almost
always questionable), a module procedure can appear in a submodule.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
2020-09-20 0:21 [Bug fortran/97122] New: Spurious FINAL ... must be in the specification part of a MODULE ian_harvey at bigpond dot com
` (3 preceding siblings ...)
2023-05-04 17:45 ` kargl at gcc dot gnu.org
@ 2023-05-04 19:01 ` kargl at gcc dot gnu.org
2023-05-04 22:17 ` ian_harvey at bigpond dot com
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: kargl at gcc dot gnu.org @ 2023-05-04 19:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #3)
>
> I have marked this as "waiting" pending a contrary interpretation.
>
> Cheers
>
Paul,
I asked on the J3 mailing list about the code.
https://mailman.j3-fortran.org/pipermail/j3/2023-May/014193.html
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
2020-09-20 0:21 [Bug fortran/97122] New: Spurious FINAL ... must be in the specification part of a MODULE ian_harvey at bigpond dot com
` (4 preceding siblings ...)
2023-05-04 19:01 ` kargl at gcc dot gnu.org
@ 2023-05-04 22:17 ` ian_harvey at bigpond dot com
2023-05-07 15:59 ` kargl at gcc dot gnu.org
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ian_harvey at bigpond dot com @ 2023-05-04 22:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
--- Comment #6 from Ian Harvey <ian_harvey at bigpond dot com> ---
A module procedure is defined by a module subprogram (F2018 15.2.2.2p3). A
module subprogram (or any subprogram) is a syntax element (a piece of source
code), equivalent to /module-subprogram/ (see the first sentence of F2018
4.1.5p1). The things that appear after the CONTAINS in a submodule are module
subprograms (see the definitions of /submodule/ and /module-subprogram-part/).
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
2020-09-20 0:21 [Bug fortran/97122] New: Spurious FINAL ... must be in the specification part of a MODULE ian_harvey at bigpond dot com
` (5 preceding siblings ...)
2023-05-04 22:17 ` ian_harvey at bigpond dot com
@ 2023-05-07 15:59 ` kargl at gcc dot gnu.org
2023-05-07 18:41 ` anlauf at gcc dot gnu.org
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: kargl at gcc dot gnu.org @ 2023-05-07 15:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
--- Comment #7 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #5)
> (In reply to Paul Thomas from comment #3)
> >
> > I have marked this as "waiting" pending a contrary interpretation.
> >
> > Cheers
> >
>
> Paul,
>
> I asked on the J3 mailing list about the code.
>
> https://mailman.j3-fortran.org/pipermail/j3/2023-May/014193.html
I haven't had a response from a current member of J3. Bob Corbett,
a former member, believes the code is valid Fortran. Jeff Hammond
notes that Cray Fortran compiled the code. So, we have Cray, Intel
compile the code. NAG and gfortran reject it. I'm not sure if there
are any other compilers with submodule support.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
2020-09-20 0:21 [Bug fortran/97122] New: Spurious FINAL ... must be in the specification part of a MODULE ian_harvey at bigpond dot com
` (6 preceding siblings ...)
2023-05-07 15:59 ` kargl at gcc dot gnu.org
@ 2023-05-07 18:41 ` anlauf at gcc dot gnu.org
2023-05-08 1:16 ` kargl at gcc dot gnu.org
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: anlauf at gcc dot gnu.org @ 2023-05-07 18:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #7)
> I haven't had a response from a current member of J3. Bob Corbett,
> a former member, believes the code is valid Fortran. Jeff Hammond
> notes that Cray Fortran compiled the code. So, we have Cray, Intel
> compile the code. NAG and gfortran reject it. I'm not sure if there
> are any other compilers with submodule support.
Nvidia accepts it too.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
2020-09-20 0:21 [Bug fortran/97122] New: Spurious FINAL ... must be in the specification part of a MODULE ian_harvey at bigpond dot com
` (7 preceding siblings ...)
2023-05-07 18:41 ` anlauf at gcc dot gnu.org
@ 2023-05-08 1:16 ` kargl at gcc dot gnu.org
2023-05-08 6:09 ` pault at gcc dot gnu.org
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: kargl at gcc dot gnu.org @ 2023-05-08 1:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #7)
> (In reply to kargl from comment #5)
> > (In reply to Paul Thomas from comment #3)
> > >
> > > I have marked this as "waiting" pending a contrary interpretation.
> > >
> > > Cheers
> > >
> >
> > Paul,
> >
> > I asked on the J3 mailing list about the code.
> >
> > https://mailman.j3-fortran.org/pipermail/j3/2023-May/014193.html
>
> I haven't had a response from a current member of J3. Bob Corbett,
> a former member, believes the code is valid Fortran. Jeff Hammond
> notes that Cray Fortran compiled the code. So, we have Cray, Intel
> compile the code. NAG and gfortran reject it. I'm not sure if there
> are any other compilers with submodule support.
Malcolm Cohen from NAG has responded in the J3 list
that it's a bug in nagfor, and the code in the bug
report is conforming Fortran.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
2020-09-20 0:21 [Bug fortran/97122] New: Spurious FINAL ... must be in the specification part of a MODULE ian_harvey at bigpond dot com
` (8 preceding siblings ...)
2023-05-08 1:16 ` kargl at gcc dot gnu.org
@ 2023-05-08 6:09 ` pault at gcc dot gnu.org
2023-05-23 5:33 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: pault at gcc dot gnu.org @ 2023-05-08 6:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
--- Comment #10 from Paul Thomas <pault at gcc dot gnu.org> ---
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
(In reply to kargl from comment #9)
> (In reply to kargl from comment #7)
> > (In reply to kargl from comment #5)
> > > (In reply to Paul Thomas from comment #3)
> > > >
> > > > I have marked this as "waiting" pending a contrary interpretation.
> > > >
> > > > Cheers
> > > >
> > >
> > > Paul,
> > >
> > > I asked on the J3 mailing list about the code.
> > >
> > > https://mailman.j3-fortran.org/pipermail/j3/2023-May/014193.html
> >
> > I haven't had a response from a current member of J3. Bob Corbett,
> > a former member, believes the code is valid Fortran. Jeff Hammond
> > notes that Cray Fortran compiled the code. So, we have Cray, Intel
> > compile the code. NAG and gfortran reject it. I'm not sure if there
> > are any other compilers with submodule support.
>
> Malcolm Cohen from NAG has responded in the J3 list
> that it's a bug in nagfor, and the code in the bug
> report is conforming Fortran.
OK That's good enough for me :-) Changing to new.
Paul
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
2020-09-20 0:21 [Bug fortran/97122] New: Spurious FINAL ... must be in the specification part of a MODULE ian_harvey at bigpond dot com
` (9 preceding siblings ...)
2023-05-08 6:09 ` pault at gcc dot gnu.org
@ 2023-05-23 5:33 ` cvs-commit at gcc dot gnu.org
2023-09-07 19:04 ` anlauf at gcc dot gnu.org
2023-09-09 11:00 ` pault at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-05-23 5:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>:
https://gcc.gnu.org/g:056280dea422ba831e40dee9e6769862927998c6
commit r14-1081-g056280dea422ba831e40dee9e6769862927998c6
Author: Paul Thomas <pault@gcc.gnu.org>
Date: Tue May 23 06:33:44 2023 +0100
Fortran: Allow declaration of finalizable DT in a submodule [PR97122]
2023-05-23 Paul Thomas <pault@gcc.gnu.org>
Steven G. Kargl <kargl@gcc.gnu.org>
gcc/fortran
PR fortran/97122
* decl.cc (variable_decl): Clean up white space issues.
(gfc_match_final_decl): Declaration of finalizable derived type
is allowed in a submodule.
gcc/testsuite/
PR fortran/97122
* gfortran.dg/finalize_8.f03 : Replace testcase that checks
declaration of finalizable derived types in submodules works.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
2020-09-20 0:21 [Bug fortran/97122] New: Spurious FINAL ... must be in the specification part of a MODULE ian_harvey at bigpond dot com
` (10 preceding siblings ...)
2023-05-23 5:33 ` cvs-commit at gcc dot gnu.org
@ 2023-09-07 19:04 ` anlauf at gcc dot gnu.org
2023-09-09 11:00 ` pault at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: anlauf at gcc dot gnu.org @ 2023-09-07 19:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |rejects-valid
Status|NEW |WAITING
--- Comment #12 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-14.
Shall we close it? Or does it deserve backporting?
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
2020-09-20 0:21 [Bug fortran/97122] New: Spurious FINAL ... must be in the specification part of a MODULE ian_harvey at bigpond dot com
` (11 preceding siblings ...)
2023-09-07 19:04 ` anlauf at gcc dot gnu.org
@ 2023-09-09 11:00 ` pault at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: pault at gcc dot gnu.org @ 2023-09-09 11:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
--- Comment #13 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to anlauf from comment #12)
> Fixed on mainline for gcc-14.
>
> Shall we close it? Or does it deserve backporting?
Hi Harald,
I was considering a backport of a composite finalization patch to bring
13-branch up to the same state as trunk. Since 13.2 has been released, this, or
fairly soon, seems like a good time to do it.
I am 200% tied up in daytime work for another two weeks and will return to this
and completion of the associate work then.
Cheers
Paul
^ permalink raw reply [flat|nested] 14+ messages in thread