(j3.2006) does move_alloc violate restrictions in 184.108.40.206?
Kurt W Hirchert
Wed Oct 28 20:12:50 EDT 2009
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)
> 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 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 220.127.116.11 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?
More information about the J3