[J3] US-12 apparently incomplete

Malcolm Cohen malcolm at nag-j.co.jp
Mon Sep 27 00:20:13 UTC 2021 

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 --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210927/0a989a73/attachment.htm>

More information about the J3 mailing list