[J3] US-12 apparently incomplete

[Malcolm Cohen]

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!

 

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:

a.	SOURCE= as there would be a copying (allocation) of the coarray components
b.	DEALLOCATE if the object is CLASS(*)
c.	Intrinsic assignment if the object is CLASS(*)

 

To treat these one-by-one:

a.	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];

b.	the dynamic type should not be allowed to have coarray components;
c.	the dynamic type should not be allowed to have coarray components.

 

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