(j3.2006) CO_BROADCAST vs. CO_REDUCE

Tobias Burnus burnus
Thu Sep 18 02:35:33 EDT 2014


Dear all,

On 17.09.2014 11:55, John Reid wrote:
> Tobias Burnus wrote:
>> looking at the current draft of the T18508, I wonder why CO_BROADCAST
>> accepts polymorphic arguments while CO_REDUCE doesn't. [...]
> Is it to allocatable coarray components that you object?

Actually, I only wonder about the asymmetry between the two. I would 
either permit for both polymorphic arguments or for neither. (I don't 
see a technical reason why one permits it for one and not for the other.)


Regarding CO_REDUCE's OPERATOR: Can one reduce the flexibility of that 
function a bit? For instance, the current wording permits that the 
arguments have either the VALUE attribute or not. It also seems to 
permit elemental arguments and ? possibly ? having  an elemental 
function with an array for one argument and a scalar for the other 
argument, C binding seems to be also permitted. I have not thought about 
how exactly I would implement it in the compiler, but reducing the 
complexity of OPERATOR would surely help.

(Currently, it looks as if I would generate a wrapper function on the 
fly while compiling to normalize the interface and use that one as entry 
point for the library. But that will require more thinking.)

> For CO_BROADCAST, we used to require SOURCE to be a coarray (see N1996). It
> seems to me that we should not allow a type with a coarray component for
> either CO_BROADCAST or CO_REDUCE.

Good point ? or at least if it is permitted, one has to be more careful 
on the implementation side. (At least for the way coarrays and 
type(lock_type) are implemented in gfortran.)

Tobias



More information about the J3 mailing list