[J3] finalization and submodule

[Jeff Hammond]

Cray Fortran 15.0.0 also compiles the code in question without incident.

Jeff

> On 7. May 2023, at 9.14, Robert Corbett via J3 <j3 at mailman.j3-fortran.org> wrote:
>
> External email: Use caution opening links or attachments
>
>
> I am no longer a member of the committee, so my opinion is only my opinion.  I agree with the argument given that the program shown is standard conformant.  I do not see any difficulty with implementing the behavior implied by the program.  Intel’s implementation is evidence that it can be implemented.
>
> Bob Corbett
>
>> On May 6, 2023, at 10:49 PM, Steven G. Kargl via J3 <j3 at mailman.j3-fortran.org> wrote:
>>
>> 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
>