[J3] US-12 apparently incomplete

[John Reid]

Steven,

I have now written a draft paper for HPC to consider. Comments from you 
would be welcome, too.

Cheers,

John.


Steven G. Kargl via J3 wrote:
> On Sun, Aug 22, 2021 at 08:54:25PM +0100, John Reid via J3 wrote:
>> Steven G. Kargl wrote:
>>> On Sun, Aug 22, 2021 at 12:06:38PM +0100, John Reid via J3 wrote:
>>>> Dear all,
>>>>
>>>> Sorry to be slow to reply to this.
>>>>
>>>> I have come to the conclusion that a problem occurs if an <allocate-object>
>>>> is unlimited polymorphic and is given a dynamic type with a coarray ultimate
>>>> component by <type-spec> or <source-expr>. This could mean that whether the
>>>> ALLOCATE statement is an image control statement is dynamic. The same goes
>>>> for the DEALLOCATE statement for the object. We need to disallow this. We
>>>> could effect this by keeping
>>>>
>>>> C953 (R932) The declared type of <source-expr> shall not have a coarray
>>>> ultimate component.
>>>>
>>>> and adding a similar constraint on <type-spec>,
>>> I have 18-007r1.  Doesn't this constraint already exist?
>>> Did the current working draft delete C937?
>> Yes. This constraint is not present in 21-007r1.
>>
> Thanks John.  I've found 21-00r1 on the J3 server.
>

-------------- next part --------------
To: J3                                                     J3/21-xxx
From: John Reid
Subject: US 12, arrays of coarrays
Date: 2021-August-24
Reference: 21-007r1

Discussion
----------

For the ALLOCATE statement, the constraint
   C953 (R932) The declared type of <source-expr> shall not have a 
   coarray ultimate component. 
applies both to MOLD= and SOURCE=. It is important for SOURCE= because
an allocate statement without a coarray <allocate-object> is not an
image control statement. When an <allocate-object> is polymorphic, it 
is given a dynamic type by <type-spec> or <source-expr>. If this is 
allowed when <allocate-object> is unlimited polymorphic and the type 
has a coarray ultimate component, it could mean that whether a 
DEALLOCATE statement for the object is an image control statement is 
dynamic. C953 makes sure that this does not happen with <source-expr> 
but there is no comparable constraint for <type-spec>. Such a 
constraint is not necessary for a polymorphic <allocate-object> with a 
declared type that has a coarray ultimate component and the constraint 
on MOLD= is not needed in this case either. 

I propose moving the SOURCE= part of C953 to C952, deleting the MOLD=
part of C953 and adding this normative restriction:
"If an <allocate-object> is unlimited polymorphic, the dynamic type of 
neither <type-spec> nor <source-expr> shall have a coarray ultimate 
component."

While looking at 21-007r1, I noticed an error in a note, and places
where the text appears not to cover adequately the case of an object 
with a coarray ultimate component. Edits are proposed for these. 

Edits to 21-007r1

[74:7+] In 7.5.4.4 Pointer components, NOTE 1, last sentence change
"an allocatable object, a coarray, or a pointer" to "a coarray or a 
pointer" so that the sentence becomes
"An object of type grid_type cannot be a coarray or a pointer."

[142:27,30] In 9.7.1.1 Form of the ALLOCATE statement, in C652 after 
"not" add "have a coarray ultimate component," so that the constraint
becomes
"C952 (R929) If SOURCE= appears, the declared type of source-expr shall 
not have a coarray ultimate component, be EVENT_TYPE, LOCK_TYPE, or 
NOTIFY_TYPE from the intrinsic module ISO_FORTRAN_ENV, or have a 
potential subobject component of type EVENT_TYPE, LOCK_TYPE, or 
NOTIFY_TYPE."
Delete "C953 (R932) The declared type of source-expr shall not have 
a coarray ultimate component."

[143:12] In 9.7.1.1 Form of the ALLOCATE statement, at the end of 
para 5 add "If an <allocate-object> is unlimited polymorphic, the 
dynamic type of neither <type-spec> nor <source-expr> shall have a 
coarray ultimate component."

[143:34-35] In 9.7.1.2 Execution of an ALLOCATE statement, para 4, 
change sentence 3 to
"If the coarray is a dummy argument or a subobject of a dummy argument, 
the ultimate argument (15.5.2.3) of the dummy argument shall be the 
same object on those images."

[147:10-11] In 9.7.3.2 Deallocation of allocatable variables, change
para 11 to 
"If a DEALLOCATE statement that deallocates a coarray has an 
<allocate-object> that is a dummy argument or a subobject of a dummy 
argument, the ultimate argument (15.5.2.3) of the dummy argument shall 
be the same object on those images."

[148:7&9] In 9.7.4 STAT= specifier, para 5,
in sentence 1 change "with a coarray <allocate-object>" to
"that is an image control statement (11.7.1)"
and in sentence 2 change "an <allocate-object> is a coarray" to
"the statement is an image control statement"
so that the two sentences become
"If an ALLOCATE or DEALLOCATE statement that is an image control 
statement (11.7.1) is executed when the current team contains a stopped 
image, the stat-variable becomes defined with the value 
STAT_STOPPED_IMAGE from the intrinsic module ISO_FORTRAN_ENV (16.10.2).
Otherwise, if the statement is an image control statement, the current 
team contains a failed image, and no other error condition occurs, the 
stat-variable becomes defined with value STAT_FAILED_IMAGE from the 
intrinsic module ISO_FORTRAN_ENV."