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

Thu Apr 15 13:35:34 UTC 2021

Reinhold,

Bader, Reinhold via J3 wrote:
> Hi Anton,
>
> your example would still be permitted even if the restriction John has proposed apply.
> One could regard it as a workaround, although it would be rather a chore to do if
> the POINTER/ALLOCATABLE component gets added to the type later on, especially if there
> are many static type components.
>
> Undefined may well be inappropriate. The question is whether it makes sense to say
>
> (1) OPERATION shall not define POINTER/ALLOCATABLE components of its result variable

Also, it must not reference them.
> (2) POINTER/ALLOCATABLE components of the actual argument in the CO_REDUCE call retain their (image-local) value
>
> Of course, this deviates from "intrinsic assignment", so may not be desirable just for that reason.

I am not a compiler writer, so I do not know how hard it would be to 
copy across just the nonpointer nonallocatable components. I do know 
that I can write co-reduce with my restrictions as a Fortran subroutine 
that has access to the type. I cannot do this with your relaxation.

Cheers,

John.
>
> Cheers
> Reinhold
>
> -----Ursprüngliche Nachricht-----
> Von: Shterenlikht, Anton <anton.shterenlikht at hpe.com>
> Gesendet: Donnerstag, 15. April 2021 14:21
> An: General J3 interest list <j3 at mailman.j3-fortran.org>
> Cc: Bader, Reinhold <Reinhold.Bader at lrz.de>
> Betreff: Re: [J3] Coarrays + CO_REDUCE and (polymorphic) allocatable components
>
>
>
>> On 15 Apr 2021, at 13:02, Bader, Reinhold via J3 <j3 at mailman.j3-fortran.org> wrote:
>>
>> It seems a little bit too draconian to entirely forbid this. You might
>> have a type with both static components and POINTER/ALLOCATABLE components, where only the former are processed through OPERATION.
>>
>> Would it not be sufficient to say the result is undefined if OPERATION modifies any POINTER/ALLOCATABLE components?
> I'd be very much against adding more undefined behaviour to the standard.
>
> Did I understand correctly that you want to allow something like this (extending the example from that section)?
>
>        TYPE T
>           LOGICAL :: zzz
>           INTEGER, ALLOCATABLE :: ia(:)
>        END TYPE T
>
>        SUBROUTINE co_all(boolean)
>           TYPE(T) INTENT(INOUT) :: boolean
>           CALL CO_REDUCE(boolean%zzz,both)
>         CONTAINS
>           PURE FUNCTION both(lhs,rhs) RESULT(lhs_and_rhs)
>             LOGICAL, INTENT(IN) :: lhs,rhs
>             LOGICAL :: lhs_and_rhs
>             lhs_and_rhs = lhs .AND. rhs
>           END FUNCTION both
>         END SUBROUTINE co_all
>
> Anton
>
>
>> Cheers
>> Reinhold
>>
>> -----Ursprüngliche Nachricht-----
>> Von: J3 <j3-bounces at mailman.j3-fortran.org> Im Auftrag von John Reid
>> via J3
>> Gesendet: Donnerstag, 15. April 2021 13:48
>> An: General J3 interest list <j3 at mailman.j3-fortran.org>
>> Cc: John Reid <John.Reid at stfc.ac.uk>
>> Betreff: Re: [J3] Coarrays + CO_REDUCE and (polymorphic) allocatable
>> components
>>
>> Dear all,
>>
>> Here is a draft interp. on this topic. Any comments before I send it in?
>>
>> John.
>>
>>
>> Bill Long via J3 wrote:
>>> 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
>>>
>>>
>>>
>>>