(j3.2006) MOVE_ALLOC with coarrays: Add STAT= forSTAT_STOPPED_IMAGE?

Malcolm Cohen malcolm
Thu Oct 24 02:42:58 EDT 2013


>this email is motivated by a question in comp.lang.fortran by someone
>who observed that ALLOCATE/DEALLOCATE statements have a STAT=/ERRMSG=
>while MOVE_ALLOC doesn't.

Right, but in practice DEALLOCATE (for noncoarrays) only fails with 
disassociated/unallocated/nonallocated arguments (trivial to avoid, and 
inapplicable to MOVE_ALLOC) or the memory allocator finds something internal is 
corrupted, in the latter case you are already living on borrowed time.

>However, for coarrays MOVE_ALLOC is also an image control statement ?
>and collective deallocation is much more likely to fail (e.g. with
>STAT_STOPPED_IMAGE). Thus, one might consider adding "dealloc-opt"-like
>optional dummy arguments for error recovery.

If an image has entered normal termination while other images are still wanting 
to allocate/deallocate/move_alloc coarrays it owns, you are already in a world 
of pain; why would an image STOP - it is clearly a mistake in the program to 
STOP in the middle of a calculation it is expected to continue to take part in!

That said, it is clearly a good idea to have STAT= and ERRMSG= arguments so that 
those who do put the effort in can attempt to recover and continue with the 
unstopped images.

Reinhold writes:
>Also, even if the DEALLOCATE in itself does not fail, adding the STAT is 
>necessary to enable continuing execution with failed images in the current team 
>(as far as the TS is concerned).

The inconsistency between DEALLOCATE and MOVE_ALLOC, given the existence of 
STAT_STOPPED_IMAGE which makes it reasonably possible to happen, mean that this 
is a "simple inconsistency or deficiency" in Fortran 2008 and therefore could be 
better categorised as a "wart" that F2015 should be addressing.

I don't think STAT_FAILED_IMAGE really brings anything new to the table here, 
and maybe less since the difficulty of recovering successfully from a 
STAT_FAILED_IMAGE must be lower than STAT_STOPPED_IMAGE where at least the data 
on the problem image is still available.

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




More information about the J3 mailing list