(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