(j3.2006) CO_BROADCAST vs. CO_REDUCE

[Bill Long]

On Sep 18, 2014, at 1:17 PM, Tobias Burnus <burnus at net-b.de> wrote:

> On 18.09.2014 14:40, Bill Long wrote:
>> Evidently the TS needs clearer wording here.  Considering that the OPERATOR function will be called from a library routine almost certainly written in C that has no visibility of the Fortran interface, it is not reasonable to allow dummy argument declarations that would require an interface.   The name (normal or bind(c)) of the function is not an issue, since the CO_REDUCE routine will be getting access to the function through a dummy argument
> 
> Well, I was thinking of argument passing: If you pass a CHARACTER, 
> non-bind(C) function expects in a typical implementation a hidden length 
> argument while a BIND(C) procedure has no hidden argument and expects 
> either a length-1 character or a TS29113 array descriptor.
> 
> I think permitting BIND(C) would be useful, permitting non-BIND(C) would 
> be useful - and not excluding character strings from CO_REDUCE would be 
> useful as well ?

The call to CO_REDUCE nominally only supplies the address of A and the entry point for the OPERATOR function.  For most processors, the bind(c)/no-bind(c) distinction is mainly in the name mangling, which is not relevant in this case.  The point about CHARACTER is valid.  Since CO_REDUCE is an intrinsic, the compiler is allowed to use special handling at the call site, such as ignoring the character length.  However, the OPERATOR function will have to know the character length by some other mechanism. 


> 
>>  (normally a pointer to the entry point of the function).  The arguments should be passed by the mechanism that would be used for scalar arguments with no attributes specified that would require a special passing mechanism (such as VALUE, ALLOCATABLE, POINTER, OPTIONAL, ?).  Since we say the function is pure, if VALUE is not allowed, INTENT(IN) becomes required.
> 
> I disagree with the last sentence: Certainly, PURE works with VALUE 

The last sentence was just a restatement of a constraint.  A nonpointer dummy argument of a pure function has to have VALUE or INTENT(IN).  It is allowed to have both.  But, if we disallow VALUE (because of not having an interface visible to the C library caller), then INTENT(IN) is required. 


> instead of (or additionally to) INTENT(IN). There was some 
> interpretation request for it. gfortran -std=f2003 claims that it is 
> valid since Fortran 2008, but it might also already be in some F2003 
> corrigenda.
> 
> The question is how to handle arrays: Does one permit elemental 
> functions? Does one permit nonelemental functions with array arguments? 

Generally, yes. Nonelemental functions can have array arguments.  In the case where you are not allowed to pass the shape as an argument, the program needs to supply  a mechanism (for example, a protected variable or named constant in a module) for the OPERATOR  function to know the shape of the array, or the shape is known to be a particular (set of)  constant(s).  However, that is not consistent with the current specification for the argument A in CO_REDUCE.  It says the operation is applied element-by-element to A, implying that the dummy arguments of OPERATOR are scalars.  This imitates the effect of having OPERATOR being elemental, even though that is not possible because of the visible interface requirement. 

> And what shall a compiler do for a nonelemental pure function when 
> invoked for an array?


A scalar dummy argument can be associated with an array actual argument  only if the function is elemental.  It is always possible to ?wrap? an array as a component of a scalar variable of derived type.  Making the OPERATOR function elemental, as noted above, has the problem of needing an explicit interface visible in the caller, and the caller is likely a C library routine.

Cheers,
Bill



> 
> Tobias
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Suport  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101