(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, 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.
Yes.
>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
time!
>Actually, I think F2008 with IR F08/0040 does not clearly state that TO gets
>deallocated.
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
deallocated"
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
>C541.
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.
Cheers,
--
................................Malcolm Cohen, Nihon NAG, Tokyo.
More information about the J3
mailing list