[Patch, Fortran] Add CO_BROADCAST

[Alessandro Fanfarillo]

Hi, I'm implementing the co_broadcast on libcafmpi right now.

2014-09-25 8:08 GMT+02:00 Tobias Burnus <burnus@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 <burnus@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
>
>