[Bug fortran/97122] New: Spurious FINAL ... must be in the specification part of a MODULE

[Bug fortran/97122] New: Spurious FINAL ... must be in the specification part of a MODULE

[ian_harvey at bigpond dot com]

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

            Bug ID: 97122
           Summary: Spurious FINAL ... must be in the specification part
                    of a MODULE
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ian_harvey at bigpond dot com
  Target Milestone: ---

When compiling the following, recent master (and 10.2.1) issues an error 

  Error: Derived type declaration with FINAL at (1) must be in the
specification part of a MODULE

There is no such requirement in the language.



MODULE m
  IMPLICIT NONE
  INTERFACE
    MODULE SUBROUTINE other
      IMPLICIT NONE
    END SUBROUTINE other
  END INTERFACE
END MODULE m

SUBMODULE (m) s
  IMPLICIT NONE
  TYPE :: t
  CONTAINS
    FINAL :: p
  END TYPE t
CONTAINS
  SUBROUTINE p(arg)
    TYPE(t), INTENT(INOUT) :: arg
  END SUBROUTINE p

  MODULE SUBROUTINE other
  END SUBROUTINE other
END SUBMODULE s



]$ gfortran -v -c 2020-09-20\ final.f90
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-pc-linux-gnu
Configured with: .././src/configure --prefix=/home/MEGMS2/ian/usr/gcc-11.0.0
--enable-languages=c,c++,fortran,lto --enable-libgomp --enable-checking=release
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200919 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=x86-64'
 /home/MEGMS2/ian/usr/gcc-11.0.0/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/f951
2020-09-20 final.f90 -quiet -dumpbase 2020-09-20 final.f90 -dumpbase-ext .f90
-mtune=generic -march=x86-64 -version -fintrinsic-modules-path
/home/MEGMS2/ian/usr/gcc-11.0.0/lib/gcc/x86_64-pc-linux-gnu/11.0.0/finclude
-fpre-include=/usr/include/finclude/math-vector-fortran.h -o /tmp/ccPu3yxp.s
GNU Fortran (GCC) version 11.0.0 20200919 (experimental) (x86_64-pc-linux-gnu)
        compiled by GNU C version 11.0.0 20200919 (experimental), GMP version
6.1.2, MPFR version 4.0.2-p9, MPC version 1.1.0, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 11.0.0 20200919 (experimental)
(x86_64-pc-linux-gnu)
        compiled by GNU C version 11.0.0 20200919 (experimental), GMP version
6.1.2, MPFR version 4.0.2-p9, MPC version 1.1.0, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
2020-09-20 final.f90:14:10:

   14 |     FINAL :: p
      |          1
Error: Derived type declaration with FINAL at (1) must be in the specification
part of a MODULE

[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE

[kargl at gcc dot gnu.org]

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.

[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE

[pault at gcc dot gnu.org]

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

[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE

[pault at gcc dot gnu.org]

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

[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE

[kargl at gcc dot gnu.org]

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

[kargl at gcc dot gnu.org]

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

[ian_harvey at bigpond dot com]

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/).

[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE

[kargl at gcc dot gnu.org]

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

[anlauf at gcc dot gnu.org]

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

[kargl at gcc dot gnu.org]

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

[pault at gcc dot gnu.org]

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

[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE

[cvs-commit at gcc dot gnu.org]

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.

[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE

[anlauf at gcc dot gnu.org]

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

[pault at gcc dot gnu.org]

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