Mon Nov 9 05:30:14 EST 2015
On 11/03/15 13:44, Van Snyder wrote:
> On the other hand, suppose X is allocatable and allocated, and one
> call move_alloc ( X, X )
> 13.7.118p6 (in 10-007r2) says X (FROM) has become deallocated. But
> 13.7.118p4 says X (TO) has become allocated. The TO argument
> description says it's INTENT(OUT), so the first thing that happens is to
> deallocate X. But 13.7.118p4 says that TO (X) becomes allocated if FROM
> (X) is allocated "on entry." Is "on entry" before or after INTENT(OUT)
> deallocates it? Is X allocated or deallocated after the call? If
> allocated, was its allocation status "affected?"
> Do we need to add a caveat about FROM and TO being different entities?
> Does this need an interp?
I have a program that uses MOVE_ALLOC to swap two allocations in an array.
The code sequence is similar to
CALL MOVE_ALLOC(FROM=A(I)%COMP, TO=TEMP)
CALL MOVE_ALLOC(FROM=A(J)%COMP, TO=A(I)%COMP)
CALL MOVE_ALLOC(FROM=TEMP, TO=A(J)%COMP)
where COMP is an allocatable component. The code does not check if I and
J are equal, and they can be. The effect of the code is well defined
under the current definition of MOVE_ALLOC, because the FROM argument of
the second call is unallocated if the arguments are the same. Requiring
the arguments of MOVE_ALLOC to be different entities would cause this code
to cease to be standard conforming.
I doubt that this is the only program that uses MOVE_ALLOC to swap two
allocations without checking if the allocatable entities being swapped
are the same.
More information about the J3