[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122 --- Comment #13 from Paul Thomas --- (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
[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
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?
[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122 --- Comment #11 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:056280dea422ba831e40dee9e6769862927998c6 commit r14-1081-g056280dea422ba831e40dee9e6769862927998c6 Author: Paul Thomas Date: Tue May 23 06:33:44 2023 +0100 Fortran: Allow declaration of finalizable DT in a submodule [PR97122] 2023-05-23 Paul Thomas Steven G. Kargl 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.
[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122 Paul Thomas changed: What|Removed |Added Status|WAITING |NEW --- Comment #10 from Paul Thomas --- 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
[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
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.
[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
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.
[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
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.
[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122 --- Comment #6 from Ian Harvey --- 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/).
[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
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
[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
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.
[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122 Paul Thomas changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from Paul Thomas --- 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
[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Blocks||37336 --- Comment #2 from Paul Thomas --- 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
[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
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.
