[J3] finalization and submodule

Robert Corbett rpcorbett at att.net
Sun May 7 06:19:15 UTC 2023


I suggest asking a member of the committee to file the interpretation request for you.  The committee has rules about the form of an interpretation request.  Members of the committee should know where to find the rules.

Bob Corbett

> On May 6, 2023, at 11:08 PM, Bader, Reinhold via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> As far as I can see, the code is conforming. A type definition (with or without a finalizer) is part of the specification part of any program unit, including a submodule.
> 
> Cheers
> Reinhold
> ________________________________________
> Von: J3 <j3-bounces at mailman.j3-fortran.org> im Auftrag von Steven G. Kargl via J3 <j3 at mailman.j3-fortran.org>
> Gesendet: Sonntag, 7. Mai 2023 07:49:18
> An: General J3 interest list
> Cc: Steven G. Kargl
> Betreff: 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



More information about the J3 mailing list