[J3] US-12 apparently incomplete
John Reid
John.Reid at stfc.ac.uk
Mon Oct 4 17:59:34 UTC 2021
Malcolm and everyone else,
I agree that it would be better for the deallocation of an object with a
coarray subobject always to involve synchronization and have constructed
a revision of 21-175 that proposes this. Any comments before I put it on
the weh site? The changes are in the first para of the discussion and in
the edit for [147:3].
John.
Malcolm Cohen via J3 wrote:
>
> Hi Reinhold,
>
> The DEALLOCATE statement for an object that has a coarray ultimate
> component is always an image control statement. It always causes
> creation of a new segment.
>
> However, according to the current text, there is only synchronisation
> if the coarray ultimate component is allocated prior to the
> DEALLOCATE. For the purposes of coarray execution, that makes the
> DEALLOCATE statement equivalent to SYNC MEMORY – a new segment is
> created, but there is no synchronisation at that time.
>
> This would seem to make using coarray components of allocatable
> variables somewhat error-prone, as the user won’t know without
> checking the allocation status of every coarray component, whether
> there will be a synchronisation. Especially if there are multiple
> coarray components and the allocatable variable is an array, it would
> seem tedious to have to scan the whole array to check for “is sync
> going to happen”, and to issue a SYNC ALL if it is not.
>
> I too wonder whether it would be better to always have synchronisation
> of such a DEALLOCATE. The argument against would be that when they are
> all deallocated, the current formulation has no sync overhead.
> Frankly, although I take the point that unnecessary syncs are harmful,
> encouraging data races (by making it harder for the user to reason
> about segment ordering) is also harmful.
>
> Cheers,
>
> --
>
> ..............Malcolm Cohen, NAG Oxford/Tokyo.
>
> *From:* J3 <j3-bounces at mailman.j3-fortran.org> *On Behalf Of *Bader,
> Reinhold via J3
> *Sent:* Friday, September 24, 2021 4:37 PM
> *To:* General J3 interest list <j3 at mailman.j3-fortran.org>
> *Cc:* Bader, Reinhold <Reinhold.Bader at lrz.de>
> *Subject:* Re: [J3] US-12 apparently incomplete
>
> Hello John,
>
> you write
> "it is undesirable to have a data value determine whether a statement
> is an image control statement."
>
> This undesirable situation, however, would also arise for executing a
> DEALLOCATE on a non-coarray object with an ultimate coarray component,
> because the component might be unallocated prior to execution of the
> DEALLOCATE statement.
>
> It seems that this situation is not covered yet by the current text.
> Is it intended that synchronization happens anyway?
>
> Regards
> Reinhold
>
> -----Ursprüngliche Nachricht-----
> Von: J3 <j3-bounces at mailman.j3-fortran.org
> <mailto:j3-bounces at mailman.j3-fortran.org>> Im Auftrag von John Reid
> via J3
> Gesendet: Dienstag, 21. September 2021 15:25
> An: General J3 interest list <j3 at mailman.j3-fortran.org
> <mailto:j3 at mailman.j3-fortran.org>>
> Cc: John Reid <John.Reid at stfc.ac.uk <mailto:John.Reid at stfc.ac.uk>>
> Betreff: Re: [J3] US-12 apparently incomplete
>
> Dear all,
>
> Three weeks have passed and there have been no comments, but I have
> found more glitches myself and I have expanded the discussion a bit,
> hopefully to make it clearer. Here it is. Comments, please. I plan to
> put it on the web site at the end of this week.
>
> Cheers.
>
> John.
>
>
> John Reid wrote:
> > 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
> <mailto: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
> <mailto:j3 at mailman.j3-fortran.org>>
> >>>> *Cc:* John Reid <John.Reid at stfc.ac.uk <mailto: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-175r1
From: John Reid
Subject: US 12, arrays of coarrays
Date: 2021-October-4
Reference: 21-007r2
Discussion
----------
An ALLOCATE statement for a non-coarray <allocate-object> that has a
coarray ultimate component is not an image control statement because
the coarray ultimate component will be undefined so that its value
will not be able to be referenced or defined by any image. However, a
DEALLOCATE statement for such an object is an image control statement
because it might involve deallocation of the coarray ultimate component
on all the images, which would require synchronization. I think it would
be better for such a DEALLOCATE statement always to involve
synchronization and I include an edit for this. Without this change,
using coarray components of allocatable variables would be somewhat
error prone, as the user might not know whether there will be a
synchronisation without checking the allocation status of every coarray
component.
If a non-coarray <allocate-object> of unlimited-polymorphic type were
allowed to be allocated to have a dynamic type with a coarray ultimate
component its deallocation would be an image control statement. It was
intended to disallow this because it is undesirable to have a data
value determine whether a statement is an image control statement.
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= and ensures that an unlimited-
polymorphic <allocate-object> is not given a dynamic type with a
coarray ultimate component in this way but there is no comparable
constraint for <type-spec>. Such a constraint is not needed 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 restriction:
"If an <allocate-object> is unlimited polymorphic, the dynamic type of
neither <type-spec> nor <source-expr> shall have a coarray ultimate
component." It is a runtime restriction so it cannot be a constraint
but can be normative.
I have found that the subclause on the STAT= specifier for ALLOCATE
and DEALLOCATE does not allow for the deallocation of an object with
a coarray ultimate component. I propose edits to correct this.
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 subobject and cases where "component" is used when
"ultimate component" is needed. 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:3] In 9.7.3.2 Deallocation of allocatable variables, para 10, first
sentence, after "coarray" add "or an object with a coarray subobject"
to make the sentence read "When a statement that deallocates a coarray
or an object with a coarray subobject is executed, there is an implicit
synchronization of all active images in the current team."
[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."
[170:5] In 10.2.1.2 Intrinsic assignment statement, para 1, item (1),
add "ultimate" before "component" so that the item becomes
"if the variable is polymorphic it shall be allocatable, and not a
coarray or a data object with a coarray ultimate component".
[170:9] In 10.2.1.2 Intrinsic assignment statement, para 1, item (3),
add "ultimate" before "component" so that the item becomes
"the variable and expr shall be conformable unless the variable is an
allocatable array that has the same rank as expr and is not a coarray
or of a type that has a coarray ultimate component".
More information about the J3
mailing list