[J3] Coarrays + CO_REDUCE and (polymorphic) allocatable components
John Reid
John.Reid at stfc.ac.uk
Thu Apr 15 14:14:00 UTC 2021
Bill,
You say "There is hazard in lumping POINTER and ALLOCATABLE together.",
which makes me think more about my proposal. We can't allow pointer
components if we want the symantics of intrinsic assignment because they
have pointer assignments. However, if the implementtion always "pulls"
data from a remote image, allocatables work provided they are allocated
on all images and have the same shape and dynamic type. Is this what
you want?
John.
Bill Long via J3 wrote:
>
>> On Apr 15, 2021, at 7:34 AM, Bader, Reinhold via J3 <j3 at mailman.j3-fortran.org> 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
>> (2) POINTER/ALLOCATABLE components of the actual argument in the CO_REDUCE call retain their (image-local) value
> There is hazard in lumping POINTER and ALLOCATABLE together. With an allocatable component, you need to be sure the size of the component is the same on all the images, or else the OPERATION routine will not make sense. For pointers, there is the added concern that the association status of the pointer can change, or become undefined if the target is on a different image. Option (2) suggests that the actual argument is copied to a temp and the temp is used as the argument actually supplied. Besides, the argument (on at least one image) gets redefined with the resulting answer, so I don’t think that requiring no change to the argument is workable.
>
> Cheers,
> Bill
>
>
>> Of course, this deviates from "intrinsic assignment", so may not be desirable just for that reason.
>>
>> 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
>>>>
>>>>
>>>>
>>>>
> 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
>
>
>
>
More information about the J3
mailing list