[J3] US-12 apparently incomplete
John Reid
John.Reid at stfc.ac.uk
Tue Aug 31 16:25:12 UTC 2021
Whoops! Anton has pointed out that I was looking at the wrong 007. I am
very sorry.
Here is a new version. Please discard the previous one.
John.
John Reid wrote:
> Dear all,
>
> I prepared a draft paper on this, sent it to the HPC discussion forum,
> and there were no comments. Here is a revision against the new 007.
> Comments, please.
>
> John.
>
>
>
> John Reid wrote:
>> Malcolm Cohen via J3 wrote:
>>>
>>> Sorry, I do not see the problem here with type-spec or MOLD=. All
>>> allocatable components spring into existence unallocated. No
>>> communication between images is necessary!
>>>
>>
>> Oh dear! I overlooked the intention that for an object with a coarray
>> ultimate component DEALLOCATE is an image control statement, but
>> ALLOCATE is not.
>>>
>>> Even in F2008, we have
>>>
>>> TYPE t
>>>
>>> REAL,ALLOCATABLE :: c[:]
>>>
>>> END TYPE
>>>
>>> ...
>>>
>>> RECURSIVE SUBROUTINE rs
>>>
>>> TYPE(t) w ! Not a coarray, subroutine entry has no sync implied
>>> or needed
>>>
>>> ! The c component springs into existence unallocated, on each
>>> execution of rs.
>>>
>>> And US-12 lets us have ALLOCATABLE thingos with coarray components,
>>> thus
>>>
>>> TYPE(t),ALLOCATABLE :: x
>>>
>>> ALLOCATE(x) ! Not a coarray, no sync implied or needed.
>>>
>>> This is allowed, and is part of the US-12 requirements so we’re not
>>> about to delete it (unless we delete a significant part of US-12
>>> functionality). And if that is okay, there is certainly nothing
>>> wrong with
>>>
>>> CLASS(*),ALLOCATABLE :: y
>>>
>>> ALLOCATE(t::y) ! Not a coarray, no sync implied or needed.
>>>
>>> Now I do agree there are issues with coarray components:
>>>
>>> 1. SOURCE= as there would be a copying (allocation) of the coarray
>>> components
>>> 2. DEALLOCATE if the object is CLASS(*)
>>> 3. Intrinsic assignment if the object is CLASS(*)
>>>
>>> To treat these one-by-one:
>>>
>>> 1. I think(*) that the user should have to manage the coarray
>>> allocations himself, which means
>>>
>>> i)the declared type of the SOURCE= expr should not be allowed to
>>> have coarray components [CONSTRAINT],
>>>
>>> ii)for CLASS(*) only, the dynamic type ditto [RUNTIME REQUIREMENT];
>>>
>>> 2. the dynamic type should not be allowed to have coarray components;
>>> 3. the dynamic type should not be allowed to have coarray components.
>>>
>> I am fine with this and will prepare a paper for review by HPC and
>> yourself.
>>
>> Cheers,
>>
>> John.
>>
>>
>>
>>
>>> I see no grounds for relaxing the ALLOCATE/DEALLOCATE requirements
>>> if some other completely-unrelated object in the statement is a
>>> coarray. That would be extremely strange language design.
>>>
>>> (*) ASIDE: It is arguable that having the compiler manage
>>> subcomponent coarray allocations would be fine, but my opinion is
>>> that this would be too big a burden, and leads to inconsistencies
>>> with CLASS(*).
>>>
>>> Cheers,
>>>
>>> --
>>>
>>> ..............Malcolm Cohen, NAG Oxford/Tokyo.
>>>
>>> *From:* J3 <j3-bounces at mailman.j3-fortran.org> *On Behalf Of *John
>>> Reid via J3
>>> *Sent:* Sunday, August 22, 2021 8:07 PM
>>> *To:* Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org>
>>> *Cc:* John Reid <John.Reid at stfc.ac.uk>
>>> *Subject:* Re: [J3] US-12 apparently incomplete
>>>
>>> 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>, but this is too big a
>>> club because an <allocate-object> might be a polymorphic variable
>>> with a
>>> declared type that has a coarray ultimate component, or there might be
>>> other <allocate-object>s that make the statement an image control
>>> statement.
>>>
>>> I suggest deleting C953 and adding this text
>>> "If no <allocate-object> is a coarray or has a type with a coarray
>>> ultimate component and an <allocate-object> is unlimited polymorphic,
>>> the dynamic type of neither <type-spec> nor <source-expr> shall have a
>>> coarray ultimate component."
>>>
>>> While working on this, I have found what I think are minor problems
>>> with
>>> the way ALLOCATE and DEALLOCATE are described when they are image
>>> control statements. I will work with HPC to prepare a paper for the
>>> October meeting.
>>>
>>> Cheers,
>>>
>>> John.
>>>
>>> John Reid wrote:
>>> > Malcolm,
>>> >
>>> > I will try to get an answer to you tomorrow, but I will not have much
>>> > time and it is not an area that I find at all easy.
>>> >
>>> > Sorry not to be quicker.
>>> >
>>> > John.
>>> >
>>> >
>>> > Malcolm Cohen via J3 wrote:
>>> >>
>>> >> Hi folks,
>>> >>
>>> >> Paper 19-250r1 added allocatable entities containing coarray
>>> >> components, and thus deleted the constraint (on ALLOCATE) that
>>> >> type-spec shall not have an ultimate allocatable component.
>>> >>
>>> >> However, the constraint further down remains:
>>> >>
>>> >> C953 (R932) The declared type of /source-expr /shall not have a
>>> >> coarray ultimate component.
>>> >>
>>> >> Presumably (?) this should be part of C952, and thus apply only to
>>> >> SOURCE= (where it would be problematic) and not to MOLD= (where
>>> it is
>>> >> not problematic).
>>> >>
>>> >> Cheers,
>>> >>
>>> >> --
>>> >>
>>> >> ..............Malcolm Cohen, NAG Oxford/Tokyo.
>>> >>
>>> >
>>>
>>> *Disclaimer*
>>>
>>> The Numerical Algorithms Group Ltd is a company registered in
>>> England and Wales with company number 1249803. The registered office
>>> is: 30 St. Giles, Oxford, OX1 3LE, United Kingdom. Please see our
>>> Privacy Notice <https://www.nag.co.uk/content/privacy-notice> 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 --------------
To: J3 J3/21-xxy
From: John Reid
Subject: US 12, arrays of coarrays
Date: 2021-August-31
Reference: 21-007r2
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-007r2, 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-007r2
[74:5-] In 7.5.4.3 Coarray components, NOTE 1, last sentence, change
"an array, 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 C952 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 the third sentence to
"If the coarray is a dummy argument or a subobject of a dummy argument,
the ultimate argument (15.5.2.4) 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.4) 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."
More information about the J3
mailing list