gfortran Coarray status - compiler, library & GSoC

[N.M. Maclaren]

>From Las Vegas (where WG5 is going on at present).

Alessandro gave a very interesting presentation, and I was very impressed
and had a useful conversation.

There are significant changes going into the coarray TS - e.g. the RESULT
argument has been removed from the collectives, because there was a serious
incompatibility with the standard (variable definition context).

I have finally got a discussion scheduled on the progress issue, and
feedback (from experts only, please) would be welcomed - I assume that Toon
would also like a copy.  Specifically, should we require progress for
(a) atomics, events etc. or (b) all coarrays, irrespective of what the
'owning' image is doing?  Without the former, spin loops using atomics are
not required to work.  Without the latter, some programs will run like
drains.

On the other hand, asynchronous progress requires a daemon thread (or even
process), and forces serious constraints on the data use.  In particular,
no object may be accessed from both the daemon and main image thread without
synchronisation (there are no single-sided fences in any widespread
interface, including POSIX and Intel architecture).  And that means ALL
access, including initialisation and termination.  That could be a major
performance hit if it were done for all coarrays.


Regards,
Nick Maclaren.