J3/14-249r1
To:        J3
From:      Van Snyder
Subject:   Description of deallocation of allocatable objects
Date: 2014 October 08
Reference: 14-007r2

1. Introduction
===============

The description of deallocation in 6.7.3.2 is not obviously complete in
its treatment of coarrays.  By explicitly discussing synchronization
only in the context of execution of DEALLOCATE, RETURN, or END
statements, or termination of a BLOCK construct, it gives the appearance
that deallocation of a coarray because of INTENT(OUT) or automatic
deallocation of a subobject don't count.  Presumably they all cause
synchronization.  Use of the term "subcomponent" in 6.7.3.2p12 could be
confusing if the deallocated coarray is a subobject of an allocatable
component (because it's not a subcomponent).  6.7.3.2p10 saves the day,
because it says automatic deallocation is the same as executing a
DEALLOCATE statement, but the reader ought not be expected to prove such
a convoluted theorem.

Intrinsic assignment is specified in such a way as to preclude automatic
deallocation (or allocation) of allocatable coarrays, coindexed objects,
or coarray subobjects.

The result of a specification function cannot be an allocated coarray,
or have a subobject that is an allocated coarray.

Other parts of the description could be simplified.

The edits to 6.7.3.2p11-12 in 14-249r0, to make it clearer that
synchronization applies to all deallocations, explicit or automatic, had
the effect of causing synchronization for each deallocation, even if
several occur as a result of executing one DEALLOCATE statement or
invoking one procedure with several INTENT(OUT) arguments.

2. Edits to 14-007r2
====================

These edits are intended not to change technical content.

[134:28-32 6.7.3.2p2-3] Replace the paragraphs:

"When execution of a procedure is terminated by execution of a RETURN or
END statement, or when a BLOCK construct terminates, if an allocatable
local variable of the procedure or construct has the SAVE attribute, or
is a function result or a subobject thereof, it retains its allocation
status, and its definition status and value if it is allocated.
Otherwise, if it is allocated it becomes deallocated."

{It's nowhere said in 6.7.3.2 that saved local variables retain their
allocation status, definition status, and values (it is said in
5.3.16).  "Becomes" is more widely used than "will be."}

[135:4 6.7.3.2p5] Replace "a structure with" with "has".

[135:5-6 6.7.3.2p5] Replace "subobject that is an allocated allocatable
entity in the result returned by the function" with "allocated
allocatable subobject of the result".

{Presumably, 6.7.3.2p5 applies to the anonymous result in the invoking
scoping unit.}

[135:24- 6.7.3.2p10-] Insert a paragraph:

When executing a statement causes deallocation of coarrays,
synchronization occurs only once each time the statement is executed.

{6.7.1.2p4 says synchronization is tied to execution of the ALLOCATE
statement, not to each allocation of a coarray in it, so no similar
paragraph is needed there.}

[135:25-28 6.7.3.2p11] Replace "a DEALLOCATE ... coarray" with
"executing a statement deallocates a coarray".  Then move the paragraph
to [135:23+ 6.7.3.2p9+ -- before the paragraph inserted at 6.7.3.2p10-].

[135:29-31 6.7.3.2p12] Remove now redundant paragraph.

{This now explicitly covers the case of automatic deallocation, without
requiring the reader to prove a theorem based on 6.7.3.2p10.}

{The note now appears at the end of the subclause.}

3. Might be construed to be a new feature
=========================================

6.7.3.2p7 doesn't leave latitude for a processor not to deallocate an
allocatable component of the variable in intrinsic assignment if it
doesn't really need to.

[135:18 6.7.3.2p7]  Within the sentence, append "if the corresponding
subobject of <expr> is deallocated, or its shape, dynamic type, or
values of any deferred length parameters are different from those of the
corresponding subobject of <expr>".