(j3.2006) (DE)ALLOCATE with STAT= question

[Malcolm Cohen]

<<<
i.e. "C" can be allocated, "A" cannot as other images have initiated
termination of execution, and "B" is already allocated.

Which value does "stat" have at the end? Does the result depend on the
order of the allocate-object-list and if so, how?* And what's the
allocation status of A, B and C?
>>>

There is no ordering in the allocate-object-list.  The value of stat is 
processor dependent.

>(* For DEALLOCATE one can find the following, I didn't spot something regarding 
>the order for ALLOCATE: [F2008, 6.7.3.1, para. 4] "When more than one allocated 
>object is deallocated by execution of a DEALLOCATE statement, the order of 
>deallocation is processor dependent.")

It also doesn't say that ALLOCATE is not guaranteed to make you a cup of coffee, 
but that is nonetheless true.

I think you will find that if the standard included all the possible false 
statements about a Fortran program, prefixed with "It is not true that ...", the 
standard would be somewhat larger than now.

The reason there is a statement for DEALLOCATE is that one can actually test the 
ordering with a standard-conforming program.  There is no way to test the 
ordering of allocation in a standard-conforming program.

<<<
Similarly for:
   integer, allocatable :: A[*], B, C
   integer :: stat
   allocate(C, A[*])
   if (this_image() > 1) stop
   DEALLOCATE (A[*], B, C, stat=stat)

What's the value of stat and the allocation status of A, B and C?
>>>

Processor dependent.

>
>My understanding is

sadly, wrong.

> that:
>- For ALLOCATE, B remains allocated, C gets allocated and A remains unallocated

Might happen but is not guaranteed by the standard.

>- For DEALLOCATE, A remains allocated, C gets deallocated and B remains 
>unallocated

Might happen but is not guaranteed by the standard.

>- The STAT= value is STAT_STOPPED_IMAGE in all cases, independent of the order.

Not necessarily.

>Is this the correct reading? Or can be the value for STAT= also different?

(1) Each allocate-object has a processor-dependent status.
(2) the stat-variable becomes defined with a processor-dependent positive 
integer

I do not see how you can blithely ignore these clear statements in the standard.

You have two possible error conditions in the statement in each case.  There is 
only one STAT= variable.  Clearly that variable cannot simultaneously have two 
different values.  This should be a clear signal to you that your unstated 
assumption that ALLOCATE/DEALLOCATE is required to attempt all the 
allocations/deallocations, regardless of any errors in other allocate-objects, 
is false.

Indeed, this question has little to do with coarrays as such, you could have 
asked it of any ALLOCATE/DEALLOCATE with two allocate-objects in error 
especially if the errors are different.

At best the statuses are processor-dependent and the stat-variable ditto, at 
worst (and one could read the wording in the standard to mean this) the program 
is not conforming.  I do not believe that we intended this, but on the other 
hand mixing ALLOCATE/DEALLOCATE of coarrays and noncoarrays looks rather 
reckless.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.