Hi Tobias,
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?
When do you intend to implement a _gfortran_caf_co_broadcast that does
something?
Anway, the patch is OK for trunk.
Thanks
Paul
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
--
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy
