Hi Paul,
Paul Richard Thomas wrote:
In the check.c error messages, you use 'A argument'. Should you not
use 'SOURCE argument', following CO BROADCAST (SOURCE, SOURCE IMAGE [,
STAT, ERRMSG]) ? I am looking at WG5/N1983 - is there some more recent
proposal?
Looking at N2027, I see "A, SOURCE_IMAGE [, STAT, ERRMSG]". It might be
that J3/WG5 decided that SOURCE= is a bad name on all but one image as
it would for all other images a DESTINATION.
Regarding the references: I try to keep
https://gcc.gnu.org/wiki/GFortranStandards up to date; I think the
latest draft is N2027:
http://isotc.iso.org/livelink/livelink?func=ll&objId=16769292&objAction=Open
Thanks for cross checking!
When do you intend to implement a _gfortran_caf_co_broadcast that does
something?
Well, the current libgfortran/caf/single.c is fully compliant - for a
single image. (Ignoring allocatable components and the lacking
finalization.)
I intend to leave the MPI and GASNet implementation to Alessandro,
unless I feel really tempted to do it.
Anway, the patch is OK for trunk.
Thanks for the review! I committed the unmodified patch as Rev. 215579.
Tobias
On 20 September 2014 16:09, Tobias Burnus <bur...@net-b.de> wrote:
This patch adds a CO_BROADCAST and prepares a bit for CO_REDUCE.
Both functions permit arguments with allocatable components (nonpolymophic
or polymorphic), CO_BROADCAST also permits polymorphic arguments. This patch
doesn't support allocatable/polymorphic arguments but otherwise CO_BROADCAST
should work. For CO_REDUCE only some parsing/argument checking is done but
no actual implementation.
The allocatables make life harder for general coarray communication,
broadcast and reduction and have to be implemented at some point in a clever
way. I am thinking of some call-back-able function - which could also be
used for OpenMP 4.x/5.0 to handle copying to threadprivate variables and for
copyin/out to accelerators; the current spec handles allocatable components
by creating the copying code in the middle end, but that won't work for
polymorphic allocatables.
For CO_REDUCE, it becomes even harder as currently any pure function works
(elemental or not, passing arguments with array descriptor, as pointer or as
value, having a hidden string length argument or [with C binding] not etc.
Requiring packed array arguments or not, whether gfortran returns the result
as value or as argument - and possibly more). There is some J3 discussion if
one could narrow down the possibilities a bit. In any case, implementing
co_reduce requires some thinking.
The attached patch was build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
