[J3] finalization and submodule

[Malcolm Cohen]

Hi Steve,

I recommend asking NAG support when you think there may be a bug in nagfor.

FWIW, I agree it is a bug. That message from nagfor predates the existence
of submodules, and was overlooked when we implemented them. This will be
fixed shortly. 

Cheers,
-- 
..............Malcolm Cohen, NAG Oxford/Tokyo.

-----Original Message-----
From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Steven G. Kargl
via J3
Sent: Sunday, May 7, 2023 2:49 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Steven G. Kargl <kargl at uw.edu>
Subject: Re: [J3] finalization and submodule

Is the Fortran code or invalid?  Where are the instructions
for writing an official interpretation request?

-- 
steve

On Thu, May 04, 2023 at 11:59:50AM -0700, Steven G. Kargl via J3 wrote:
> All,
> 
> I have a question about finalization and submodules that is
> sparked by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
> The code in question is
> 
>    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
> 
> According to the bug report, gfortran and nagfor reject the code
> with an error message of the form
> 
>    "Error: pr97122.f90, line 14: Type T has final subroutines
>     but is not defined in the specification part of a module"
> 
> Intel's ifort compiles the code.
> 
> Using 22-077r1 (22 Apr 22), I can find
> 
>    C791  (R753) A final-subroutine-name shall be the name of a module
>       procedure with exactly one dummy argument.  That argument shall be
>       nonoptional and shall be a noncoarray, nonpointer, nonallocatable,
>       nonpolymorphic variable of the derived type being defined.  All
>       length type parameters of the dummy argument shall be assumed.
>       The dummy argument shall not have the INTENT (OUT) or VALUE
>       attribute.
> 
>    3.112.4
>    module procedure
>    procedure defined by a module subprogram, or ...
> 
>    3.143.3
>    module subprogram
>    subprogram that is contained in a module or submodule but is not
>    an internal subprogram
> 
> 
>    14.2.3 Submodules
>    ...
>    3 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.
> 
> AFAIC, 'subroutine p(arg)' meets at the requirement for finalization.
> I admit that I may have missed something in chasing 'module procedure'
> through 22-007r1.
> 
> So, the question are
>  'Are gfortran and nagfor correct in rejecting the code?'
>  'Does have Intel's ifort have bug?'
>  'Does the Fortran standard need be refined to explicitly
>   state that derived type with a final statement can only
>   appear in the specification part of a module?'
> 
> -- 
> Steve



-- 
Steve