[J3] finalization and submodule

[Steven G. Kargl]

Malcolm, 

Thanks for the comment and confirmation of a bug
in gfortran and apparently nagfor.

I don't use NAG's compiler.  I can only report that which
has been reported in a gfortran bug report.  Given NAG's
reputation for quality and gfortran agreeing with nagfor,
I was seeking clarification as wading through 18-007r1.pdf
and 23-007r1.pdf for 'module procedure' is a rather joyous
task.

-- 
steve

On Mon, May 08, 2023 at 09:48:45AM +0900, Malcolm Cohen via J3 wrote:
> 
> 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

-- 
Steve