[J3] Coarrays + CO_REDUCE and (polymorphic) allocatable components

[Bill Long]

Hi John,

The case if a pointer component is particularly problematic if the component is an array and the targets of the pointer have difference sizes on different images.  That makes specification of the result of the OPERATION function difficult at best.  We already disallow pointer arguments to OPERATION, so disallowing types with pointer ultimate components would seem consistent.  Creating a type with a pointer component seems to be a loophole to get around the rule disallowing pointer arguments to OPERATION. 

Cheers,
Bill



> On Apr 11, 2021, at 3:05 PM, John Reid via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> Bill,
> 
> I have been thinking a bit more about this. I think we need to exclude a type with a pointer ultimate component because such a component will become undefined when an object of the type is copied from another image as for an assignment, which is what I expect an implementation to do.
> 
> Cheers,
> 
> John.
> 
> 
> Bill Long via J3 wrote:
>> The restrictions on the OPERATOR function - that it be PURE - have side-effect limitations on its arguments that might cover some of your issues. For example.
>> 
>> "The function result of a pure function shall not be both polymorphic and allocatable, or have a polymorphic allocatable ultimate component.”
>> 
>> Cheers,
>> Bill
>> 
>> 
>> 
>>> On Mar 18, 2021, at 6:36 AM, Tobias Burnus via J3 <j3 at mailman.j3-fortran.org> wrote:
>>> 
>>> Hi all,
>>> 
>>> I was wondering whether the following is valid:
>>> 
>>> type t
>>>  integer, allocatable :: A(:)
>>>  type(t), allocatable :: B
>>>  class(*), allocatable :: C
>>> end type t
>>> 
>>> type(t) :: var[*]
>>> 
>>> ...
>>> call co_reduce(var, my_red_fn)
>>> 
>>> At a glance, I could not find anything which states that
>>> this is invalid, but I note that for a distributed-memory
>>> implementation, the CO_REDUCE has to remotely access
>>>  var[i]%A and var[i]%B
>>> before calling 'my_red_fn' locally – and especially
>>> resolving the dynamic type of 'B' might be difficult.
>>> 
>>> And worse is the part about distributing the data back to
>>> the result_image or all images, in particular if the
>>> shape/dynamic type does not match.
>>> 
>>> For data-ref, there is:
>>> 
>>> C917   (R911) Except as an actual argument to an
>>> intrinsic inquiry function or as the designator in a
>>> type parameter inquiry, a data-ref shall not be a
>>> coindexed object that has a polymorphic allocatable
>>> potential subobject component
>>> 
>>> C918   Except as an actual argument to an intrinsic
>>> inquiry function or as the designator in a type parameter
>>> inquiry, if the rightmost part-ref is polymorphic,
>>> no other part-ref shall be coindexed.
>>> 
>>> And for CO_REDUCE, there is: "'A' shall not be polymorphic."
>>> 
>>> 
>>> Is this intended to be valid? Did I miss some constraint?
>>> Or was this an oversight?
>>> 
>>> 
>>> Tobias
>>> 
>> Bill Long                                                                       longb at hpe.com
>> Engineer/Master , Fortran Technical Support &   voice:  651-605-9024
>> Bioinformatics Software Development                      fax:  651-605-9143
>> Hewlett Packard Enterprise/ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425
>> 
>> 
>> 
>> 
> 

Bill Long                                                                       longb at hpe.com
Engineer/Master , Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Hewlett Packard Enterprise/ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425