(j3.2006) MOVE_ALLOC with coarrays

Malcolm Cohen malcolm
Sun Jun 3 21:05:32 EDT 2012

John Reid wrote:
> This is the subject of an interp., which unfortunately was not ready in time 
> for corrigendum 1. It is F08/0040 in 12-006A

Not only was it not ready in time for corrigendum 1, it is not ready now 
either - it is still being processed.  It has not even passed a J3 letter ballot 
yet... so a long way short of final agreement.

Tobias Burnus writes:
>The allocate and the deallocate statements, require synchronization. (See 
>p.128,, paragraph 4 and p.131, And, hence, the allocate 
>statement has to be invoked on all images.


>However, I do not find such a restriction for MOVE_ALLOC. The IR only makes it 
>an image control statement; the latter implies a SYNC MEMORY and segment 
>ordering. But it seems as if one can call move_alloc only on a single image - 
>at least as long the TO argument has an initial status of being deallocated.

Indeed.  I think we just forgot that the synchronisation lists in clause 6 were 
all specific, rather than automatically covering all implicit 
allocations/deallocations.  In hindsight it would have been a good idea to have 
a single general rule instead of whacking every mole individually.  Maybe next 

>Actually, I think F2008 with IR F08/0040 does not clearly state that TO gets 

It certainly is clear.

> For noncoarrays, that's implied by INTENT(OUT).

Actually there is no mention of "noncoarrays" at all, the words are
  "When a procedure is invoked, any allocated allocatable object that is an 
actual argument corresponding to an INTENT(OUT) allocatable dummy argument is 

You cannot get much more crystal clear than that!  Obviously covers coarrays as 
well as noncoarrays, the same as it covers REAL as well as INTEGER...

>However, for allocatable coarrays, the INTENT(OUT) is explicitly prohibited via 

So what?  C541 applies to Fortran procedures, not to intrinsic procedures. 
Since MOVE_ALLOC is physically impossible to even define an interface block for 
in Fortran, let alone implement in Fortran, this is irrelevant.  We've had 
intrinsic procedures that are impossible to do in Fortran for a very long time.

>Is the following program valid?

Clearly not.  Equally clearly, not properly covered by the wording of the interp 
so far.

>And if it is valid: What's on image 1 - or alternatively image 2 - the 
>allocation status of A and B and (if allocated) the value of A[1] and A[2] or 
>B[1] and B[2]? (Assuming num_images() >= 2.)

Thus even without improving the wording of the interp, it is not valid by the 
general rule in clause 1 (the standard does not establish an interpretation for 
it).  However, I am sure that by the time we have finished with it, the wording 
will have been improved.

................................Malcolm Cohen, Nihon NAG, Tokyo. 

More information about the J3 mailing list