(j3.2006) does move_alloc violate restrictions in 12.5.2.13?

[Kurt W Hirchert]

Jim Xia wrote:
> > Kurt answered this question yesterday.  MOVE_ALLOC (at least as
> > described in the standard, independently of how IBM implements it)
> > performs all of its actions by way of its dummy arguments, not by host
> > association, not by use association, not by storage association, not by
> > construct association.
>
>
> This IS about argument association.  If it helps, consider the 
> analogies between the two calls
>
>
> CALL FOO (A, A)
>
> vs.
>
> CALL MOVE_ALLOC (FROM, TO)
>
>
> The fact is there is only ONE actual argument survives the call.  BUT, 
> during the execution of MOVE_ALLOC, it has to be associated with both 
> FROM and TO. 
1. I don't see the analogy between those CALLs.  Now, if your second 
CALL were

CALL MOVE_ALLOC (FROM=A,TO=A)

that would be analogous.  Such a call doesn't violate rule (2), but it 
does violate the first sentence of rule (1), so it is already precluded.

2. Textually, rule (2) does not apply because rule (2) places limits 
only on how entities are referenced, and the arguments of MOVE_ALLOC are 
not "referenced" in the technical meaning that word has in the 
standard.  (It may be argued, that the arguments are "defined", but 
except in the case of providing the same argument for both TO and FROM, 
such "defining" always takes place through the correct dummy argument.)

3. The technical issue 12.5.2.13 was intended to address was to allow 
optimizations of operations involving dummy arguments on the assumption 
that they are independent of each other and of any other entities being 
used in those operations.  It does this by prohibiting those cases where 
it would matter whether or not they are independent.  This issue isn't 
important in the intrinsic functions because the implementor is expected 
to have as much control over operation order as he/she needs to get the 
semantics right in the intrinsics.

4. I don't see any other technical issues in the points you have made.  
Yes, one way of implementing MOVE_ALLOC might have an intermediate state 
in which the allocation associated with the allocatable array associated 
with FROM is also associated with the allocatable array associated with 
TO, but since arbitrary user-written code is never given access to this 
"bad" state, it doesn't really matter.   (This can be seen as analogous 
to the fact that many implementations of pointer assignment may have 
"bad" intermediate states in which the pointer's dope vector holds a 
mixture of information from its new association and its old 
association.  This doesn't matter because nothing is allowed to work on 
the pointer while it is in that state.)

Has any of the above helped you?

-Kurt