Hi, I'm implementing the co_broadcast on libcafmpi right now.
2014-09-25 8:08 GMT+02:00 Tobias Burnus <bur...@net-b.de>: > 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 > >