Finalization order for complex objects: official interpretation needed?

[nncarlson]

@certik asked that I share this here.

I've encountered an issue with finalization that is illustrated by the example that follows. There is a parent type and child type that extends the parent, each with a final subroutine. The child type has two derived type components, one allocatable, the other not. The component types also have final subroutines. The point of the example is to reveal the order in which the final subroutines are called.

Two compilers produce the results I expected, namely the string "CABP" for Child, component A, component B, and Parent. "CBAP" would have been equally acceptable. A third compiler produces the string "CBPA". The preliminary response from the vendor of the latter compiler is that the standard is ambiguous with conflicting requirements and that choice of behavior is arguably valid. They did go into some explanation, but I haven't yet understood their argument. I'll be following up with them, and as I understand more I'll comment here with it. Section 7.5.6.2 (2018) seems pretty clear to me (arguing for "CABP") but there may well be other parts of the standard that are inconsistent with it -- I have a lot of respect for this vendor. If an official interpretation and standard clarification is required I would strongly urge for "CABP".

[Edit] The core question here is why does the third compiler vendor believe the allocatable component A have to be finalized last after the parent, whereas the non-allocatable component B should be finalized before the parent.

Here is the example

module child_type

  implicit none
  private

  type :: objectA
  contains
    final :: finalize_objectA
  end type

  type :: objectB
  contains
    final :: finalize_objectB
  end type

  type :: parent
  contains
    final :: finalize_parent
  end type

  type, extends(parent), public :: child
    type(objectA), allocatable :: A
    type(objectB) :: B
  contains
    procedure :: init
    final :: finalize_child
  end type

contains

  subroutine finalize_objectA(this)
    type(objectA), intent(inout) :: this
    write(*,'("A")',advance='no')
  end subroutine

  subroutine finalize_objectB(this)
    type(objectB), intent(inout) :: this
    write(*,'("B")',advance='no')
  end subroutine

  subroutine finalize_parent(this)
    type(parent), intent(inout) :: this
    write(*,'("P")',advance='no')
  end subroutine

  subroutine finalize_child(this)
    type(child), intent(inout) :: this
    write(*,'("C")',advance='no')
  end subroutine

  subroutine init(this)
    class(child), intent(inout) :: this
    allocate(this%A)
  end subroutine

end module

program main
  use child_type
  call run
contains
  subroutine run
    type(child) :: c
    call c%init
  end subroutine
end program

[nncarlson]

A bit of background for those who might be wondering. In the actual use case, the child type is a "solver". The solver makes use of a third party framework library AMReX that the solver starts up as part of its initialization and then shuts down when the solver is deallocated or goes out of scope. The solver also has components that have framework objects as subobjects. These must be finalized before the framework is shutdown. In order to ensure that things happen in the right order, the solver extends a dummy parent type whose main purpose is to shut down the framework as part of the parent's final subroutine. Unfortunately this doesn't work with the way the third compiler behaves.

In the actual use case the allocatable component is polymorphic (hence making it non-allocatable isn't an option), but that is an extraneous feature to the core question. Interestingly, one of the compilers that gets the example "right" totally blows it for the allocatable polymorphic component case -- it never bothers to call its finalizer at all.

[klausler]

Apart from the lack of specification on the order of finalization of components, F'2018 is very clear to me on this point. "CABP" and "CBAP" are the only valid outputs. In particular, the parent component absolutely may not be finalized in step (3) until after the non-parent components have been finalized in step (2) (see 7.5.6.2).

The child's final procedure can effectively force the order "ACBP" if necessary by deallocating A in finalize_child before doing anything else.

[certik]

I agree with @nncarlson and @klausler that "CABP" and "CBAP" should be the only two valid outputs in this case.

[FortranFan]

To me, this looks worthy of an interpretation request.

[certik]

How do we submit one?

…

On Tue, Feb 25, 2020, at 3:58 PM, FortranFan wrote: To me, this looks worthy of an interpretation request. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#146?email_source=notifications&email_token=AAAFAWBXEE7GS2YSDDAAM33REWWBZA5CNFSM4KZKUGP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEM6DOHI#issuecomment-591148829>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFAWBZWO2TYYCZA2RRLFDREWWBZANCNFSM4KZKUGPQ>.

[FortranFan]

@certik wrote:

How do we submit one?
..

Start with an email to the J3 mailing list. Then as needed based on clarity and/or suitability of the response(s), draft a paper like this: https://j3-fortran.org/doc/year/20/20-102.txt

[zjibben]

There is an interp paper on this for discussion tomorrow: https://j3-fortran.org/doc/year/20/20-117.txt.

[certik]

Actually I think this paper is a little bit different if you look at the example carefully. But maybe it exposes the same issue.

…

On Wed, Feb 26, 2020, at 4:46 PM, Zach Jibben wrote: There is an interp paper on this for discussion tomorrow: https://j3-fortran.org/doc/year/20/20-117.txt. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#146?email_source=notifications&email_token=AAAFAWGWNROTW7LYMV6ADETRE4EPJA5CNFSM4KZKUGP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENCOUMY#issuecomment-591718963>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFAWGKUOQX3DUG7BV5HS3RE4EPJANCNFSM4KZKUGPQ>.

[nncarlson]

I'm not sure of what to make of the document. Rather opaque on my first reading. I hope the outcome, whatever the means, is that the required behavior is what we seem to agree is wanted. Please push for that tomorrow.

[nncarlson]

@certik the example from the document is precisely the same as the one gave in here.

[FortranFan]

@certik the example from the document is precisely the same as the one gave in here.

There is a difference in that the example in the interpretation document at the J3 website does NOT have the equivalent of 'objectB' as a component in the child derived type:

Plus there is the aspect where discussion in the interp doc addresses quite a bit the concern about an object ('OtherF') being finalized twice.

That doesn't appear in the original post here since that would have led to comments about 'A' appearing twice in the output of the program in the original post.

[certik]

Indeed, it seems different. For that reason I submitted a new one:

https://mailman.j3-fortran.org/pipermail/j3/2020-February/011838.html

For now just as an email. Based on the response and discussion tomorrow, we can submit a full request.

[nncarlson]

As @FortranFan pointed out the only difference was the addition of an objectB component. I added that simply to highlight how finalization of non-allocatable component is done differently from that for an allocatable for the one problem compiler. I should probably say "cleanup" instead of "finalization", because I sense from the interp doc, that finalization is being used in a very strict technical sense that isn't completely synonymous with what I think of naively as cleanup.
I know of no compiler that does the finalization twice like the interp doc discusses. In fact, the problem compiler of the OP is the NAG compiler, and its odd behavior is precisely to avoid finalizing twice per an explanation passed on to me from Malcolm. I still don't understand why he believes one possible interp requires finalizing twice -- I'm missing something, hopefully @certik and @zjibben will be able to explain what the problem is after today's deliberation.

[certik]

So after the discussion at plenary the paper https://j3-fortran.org/doc/year/20/20-117.txt got passed.

With the standard, as amended by 20-117, the CBPA output is allowed and ok, per standard.