[J3] [EXTERNAL] Clarification on F18/017

Mon Jun 8 07:40:46 EDT 2020

Yes - very helpful.  Thanks!

On Jun 5, 2020, at 9:38 PM, Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>> wrote:

Hi folks,

Okay, here’s the analysis of what happens with the example program, under the interp as it stands.

First up, thanks for calling the components that output “A” and “B” by the same names. Below, I’m going to call the parent component “P” too, as that is its output.

On exit from RUN,

  1.  Local variable C is finalized (7.5.6.3p3) as it is local&nonpointer&nonallocatable, and is about to become undefined.
  2.  Local variable C%A is allocated, and therefore will be deallocated (9.7.3.2p2.
  3.  Because C%A is a subobject of C, execution of the final procedure for C precedes the deallocation of C%A.

Therefore the first output is “C”, from execution of C’s final subroutine.

Now, C also has a finalizable component B (finalized in step 2) and a finalizable parent P (finalized in step 3); step 2 and 3 are carried out in sequence, so the output of “B” precedes the output of “P”.

Thus we have established the ordering C < B < P. (“<” to mean precedes).

Finally, the deallocation of C%A will produce the output “A”; this definitely follows the output “C”, but there is no ordering specified between the other components,. Given the two partial orderings C<B<P and C<A that means we could see CABP or CBAP or CBPA.

So I agree with Ondrej’s analysis here.

A few random (philosophical?) thoughts:

  1.  If there are two “ordinary” components B1 and B2 (instead of the one component B), there is no ordering between B1 and B2 in any event.
  2.  All of these possibilities follow different, but plausible, implementation technologies.
  3.  Automatic deallocation differs from finalization in several ways:

  1.  All allocatable components get automatically deallocated, no ifs buts or maybes, whereas final subroutine invocation depends on type, kind, and rank, with different (or no) final subroutines being executed with different kind type parameters or rank.
  2.  There is no implied ordering between the ultimate allocatable components deallocation, regardless of inheritance or embedding. Whereas final subroutine invocation is ordered by inheritance and embedding.

  1.  Allocatable components are from 1998, and were widely implemented fairly soon thereafter. Final subroutines are from 2004, but the initial definition was problematic, so they were changed (incompatibly) in a Corrigendum to F2008, i.e. in 2011 or later. Implementation is now widespread, but this is relatively recent.
  2.  The runtime infrastructure requirements for automatic component deallocation, and finalization, are thus rather different. For a particular type, these overlap but neither is a subset of the other (one being, like, “universal”, the other needing Kind and Rank info to be passed around so that a selected subset of the possible final subroutines are executed). This is mostly about polymorphic object handling – if nothing is polymorphic, the compiler can generate inline code for everything (though whether it should is another matter – expanding code size is not always an obvious win).
  3.  Thus there are at least two obvious implementation strategies. Strategy one: have two structures, one for auto-dealloc, one for final, and process the auto-dealloc one after the final one. Strategy two: have a unified structure that controls both, so auto-dealloc and final get processed in tandem; this structure would necessarily be somewhat more complicated than either of the two individual structures of Strategy One.
  4.  Finally, I note that Strategy One is the natural one to follow if one implemented allocatable components in 1999, but final subroutines ten years later, as one already has the structure for handling auto-dealloc, and changing that may affect backwards compatibility (not to mention introducing lots of new bugs in an old feature). But if one were starting from scratch, Strategy Two is also a very natural one to follow.

I don’t know whether those maunderings shed light or darkess; if the latter, you can just ignore them!

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

From: J3 <j3-bounces at mailman.j3-fortran.org<mailto:j3-bounces at mailman.j3-fortran.org>> On Behalf Of Malcolm Cohen via J3
Sent: Friday, June 5, 2020 8:47 AM
To: 'General J3 interest list' <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Cc: Malcolm Cohen <malcolm at nag-j.co.jp<mailto:malcolm at nag-j.co.jp>>
Subject: Re: [J3] Clarification on F18/017

Hi Ondrej,

Thanks for your question. I can do a partial answer immediately, but a full one requires analysis I probably won’t have time to do today, as I am rather snowed under and have urgent deadlines to attend to. I’ll do the full analysis asap, but could be over the weekend.

Re 1, yes it definitely precludes multiple finalization of A.
(This is where I need to study the program carefully to see which output combinations are allowed.)

Re 2, that is correct, no question about it.

I’ll get back to you as soon as I can on precisely which ordering are permitted, unfortunately now I really have to rush to prepare for an urgent meeting.

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

From: J3 <j3-bounces at mailman.j3-fortran.org<mailto:j3-bounces at mailman.j3-fortran.org>> On Behalf Of Ond?ej ?ertik via J3
Sent: Friday, June 5, 2020 3:49 AM
To: J3 Mailinglist <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Cc: Ondřej Čertík <ondrej at certik.us<mailto:ondrej at certik.us>>
Subject: [J3] Clarification on F18/017

Hi,

We have a question for the interpretation F18/017. As it was submitted for vote, and if the edits are done to the standard, what is the expected result of the program that I am attaching below? See the issue https://github.com/j3-fortran/fortran_proposals/issues/146<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_j3-2Dfortran_fortran-5Fproposals_issues_146&d=DwMFaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=EDCdNzkccJ25Co3sjWrr1HlJQ3_CoIFWfekFE1ulcLI&m=6a7eAeaQYiH-RZXH3v3jICrGrjz_tivfcqT5o7RLEpA&s=Br36nIEejDqRpk83daN-nwcQ-kzza5LX0DFg0nC1ipc&e=> for more context and background.

1. Our understanding is that the new standard would preclude multiple finalization of A (which is good), but would allow the compiler to implement any of CABP, CBAP, and CBPA call orders.

2. A program could force CABP by explicitly deallocating the allocatable component in the final procedure for the containing object.

Is both 1. and 2. correct?

Thanks,
Ondrej

----------------

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
Disclaimer
The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. Please see our Privacy Notice<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.nag.co.uk_content_privacy-2Dnotice&d=DwMFaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=EDCdNzkccJ25Co3sjWrr1HlJQ3_CoIFWfekFE1ulcLI&m=6a7eAeaQYiH-RZXH3v3jICrGrjz_tivfcqT5o7RLEpA&s=hKcskiRvi1ID9X_INK-C6D640J1JgvZ8pdTbgS1kcn8&e=>for information on how we process personal data and for details of how to stop or limit communications from us.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20200608/7b0649b7/attachment-0001.htm>