Bill Long longb
Fri Sep 19 13:32:05 EDT 2014

On Sep 19, 2014, at 1:55 AM, Malcolm Cohen <malcolm at nag-j.co.jp> wrote:

> <<<
>> The call to CO_REDUCE nominally only supplies the address of A and the entry 
>> point for the OPERATOR function.
> So, that?s not right for A.  Since A is allowed to be an array, the call will 
> somehow need to also supply element size and shape information.
> And length type parameter information.
> <<<
>  Most likely just the normal descriptor used for other intrinsics with array 
> arguments.  Internally, CO_REDUCE uses this information to generate the 
> addresses for each of the elements of A to be used in the call to OPERATOR.
> I know we all want to forget about the existence of PDTs, but unless we do 
> something they are not going to go away.  If the argument is a PDT with an 
> assumed type parameter, there is no choice other than to do whatever is 
> necessary to pass the type parameters through to it.

I agree that PDT passing can introduce complications. How this is handled probably depends on how the compiler handles passing type parameter values in general.  If they are included in the general descriptor, it might not be an issue.  If they are appended as hidden arguments at the end of the call then the easier solution is to have two versions of the CO_REDUCE routine internally, one that gets called if A has no type parameters and the other that is called if A has type parameters.  In the second case, the compiler supplies the extra information to the co_reduce_pdt routine, and internally the call to OPERATOR is fixed up with the correct arguments and values.  The reason this works is that the argument A to CO_REDUCE (which the calling code can detect as having type parameters)  and the arguments to OPERATOR have the same type parameters.  All the user call site to CO_REDUCE has to know is whether A has type parameters to select which library routine to actually call.  At least, this seems like the ?obvious? approach to me. 

> (Doing polymorphic seems no harder than handling all the other things we have to 
> handle, in fact without PDTs polymorphic is a doddle.)
> Unless we are going to declare PDTs deprecated or optional, making them 
> second-class citizens is a bad idea.
> <<<
> it is not reasonable to allow dummy argument declarations that would require an 
> interface
> The TARGET attribute does not look *that* harmful!  And BIND(C) requires an 
> interface anyway?

There is no expectation that the OPERATOR function has BIND(C).  The C code in the CO_REDUCE library routine needs to correctly construct the call to OPERATOR based on the calling rules for the Fortran compiler. 


> Cheers,
> -- 
> ................................Malcolm Cohen, Nihon NAG, Tokyo. 
> _______________________________________________
> 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

More information about the J3 mailing list