(j3.2006) MOVE_ALLOC with coarrays

[Tobias Burnus]

Dear all,

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

Thanks for the pointer. I have one problem with that IR:

The allocate and the deallocate statements, require synchronization. 
(See p.128, 6.7.1.2, paragraph 4 and p.131, 6.7.3.2p1:2.) 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.

Actually, I think F2008 with IR F08/0040 does not clearly state that TO 
gets deallocated. For noncoarrays, that's implied by INTENT(OUT). 
However, for allocatable coarrays, the INTENT(OUT) is explicitly 
prohibited via C541.

(I have to admit that I start to like the initial proposal for F08/0040 
which simply disallowed coarray arguments to move_alloc. Do to their 
cross-image nature, the move_alloc is not as useful for coarrays as for 
noncoarrays. Using move_alloc together with allocatable components of a 
derived-type coarray seems to be more useful.)


Is the following program valid?

integer, allocatable :: A[:], B[:]
allocate (A[*])
A = this_image()
if (this_image () == 1) then
   call move_alloc (A, B)
end if
sync all
! ...
end

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.)

Tobias