DO CONCURRENT vs reallocate lhs

[jimdempseyatthecove]

I was reading through the IVF document, under DO CONCURRENT and saw a requirement:

An allocatable object that is allocated in more than one iteration must be subsequently deallocated during the same iteration in which it was allocated.

An object that is allocated or deallocated in only one iteration must not be referenced, allocated, deallocated, defined, or become undefined in a different iteration.

When reallocate lhs is in effect, one is not necessarily in control of allocation/deallocation. What are the nuances of reallocate lhs verses DO CONCURRENT?

Jim Dempsey

[Steve_Lionel]

It's really no different than doing the allocations yourself - the rules still apply. It would be unusual to assign to a whole allocatable array in a DO CONCURRENT unless that was local to the iteration via BLOCK. The key is that the iterations can be done in any order and to any degree of parallelism, so any side-effects such as allocation or deallocation are not permitted across iterations.

[IanH]

Further, there's more to it than those fragments from the Intel docs imply (their wording is a bit odd anyway - if you allocate or deallocate in another iteration, then you are not allocating or deallocating in only one iteration) - see F2015 draft for details - a mere reference or definition of an allocatable variable in more than one iteration is enough to bring in the restrictions on touching its allocation status and the requirements around previous allocation in each iteration.  If you are assigning to an allocatable variable, then you are defining it, even if it doesn't get reallocated.

If there is a chance that an allocatable thing might get reallocated in more than one iteration (and an allocatable thing being assigned to (in its entirety) should be considered a chance for reallocation, in the general case), then ensure it is deallocated before the iteration completes.  The easiest way of doing that is to make the allocatable variable a local entity of a block construct that is inside the do construct.

(I always a little uncomfortable with whether definition and reference of a subobject also define or reference the complete object when considering the DO CONCURRENT rules.)

My whinge for today - F2008's do construct semantics, where the behaviour and restrictions change depending on whether more than one iteration modifies something, is a language misfeature.  Practically, using OpenMP terminology to illustrate, it means that the source writer, source reader, the compiler and its runtime, don't know whether a variable is SHARED or PRIVATE until after the construct has executed.  A better specification would have been to make all variables declared outside of the construct (excluding the iteration index) the equivalent of SHARED, if programmers wanted the equivalent of PRIVATE they should have been forced to explicitly set them up using non-saved local variables of a block construct or invoked procedure inside the do concurrent construct. It would have made the specification in F2008 much simpler, and avoided the need for all the locality stuff in F2015.  It is that much of a misfeature that I reckon that rather than adding the locality stuff, F2015 should have just broken F2008 compatibility to fix this.  Oh well.