[J3] US-12 apparently incomplete

John Reid John.Reid at stfc.ac.uk
Wed Oct 13 10:43:27 UTC 2021 

Reinhold,

Thanks for checking it and for the reminder. It is now on the web site .

John.


Bader, Reinhold wrote:
> Hi John,
>
> looks OK. You still need to put it on the web site.
>
> Cheers
> Reinhold
>
> -----Ursprüngliche Nachricht-----
> Von: J3 <j3-bounces at mailman.j3-fortran.org> Im Auftrag von John Reid via J3
> Gesendet: Montag, 4. Oktober 2021 20:00
> An: General J3 interest list <j3 at mailman.j3-fortran.org>
> Cc: John Reid <John.Reid at stfc.ac.uk>
> Betreff: Re: [J3] US-12 apparently incomplete
>
> 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.
>>>>>>

More information about the J3 mailing list