Ensure copy-in copy-out strategy for coarray arguments

[everythingfunctional]

I believe it would be a valid strategy to implement coindexed procedure actual arguments as copy-in/copy-out. This is because it would not be valid for anything to do anything which would be able to observe that the data hasn't be put where it belongs yet. We need to carefully validate that to be the case.

[everythingfunctional]

I went through the 2023 draft standard and found all the places that discuss argument association. Here are my notes from the relevant sections:

• 19.5.1.1 + 19.5.1.2
• 19.5.5
• 15.5.2.4 Note 1
• Processor dependent: the interaction between argument association + pointer association. I.e. from 15.5.1.4

  A present pointer dummy argument that does not correspond to a pointer actual argument is not argument associated.

• 7.5.4.5
• 8.5.6.2
• 8.5.7: contiguous dummy actually necessitates copy-in/copy-out for non-contiguous actual
• 8.5.19
• 15.5.2.9 Notes 1, 2, + 3
• 12.6.4.8.3
• 15.5.2.3
• 15.5.2.5 par. 9

As far as I can tell, there is nothing that would prevent us from requiring copy-in/copy-out semantics for coindexed actual arguments.

[everythingfunctional]

In response to out discussions about the interfaces for get/put for coarray access, specifically as it relates to coarrays with allocatable components, consider something like the following, which might be a valid reference.

type :: t1
  integer, allocatable :: vals(:)
end type
type :: t2
  type(t1), allocatable :: vals(:)
end type
type(t2), allocatable :: stuff(:)[:]

...
stuff(1:5:2)[n]%vals(1:7:3)%vals(3:1:-1)

I need to go read closer to see if this is something that is actually allowed, but if it is could pose a problem.

[everythingfunctional]

Looking into it a bit more, it seems the complications are at least limited to a degree:

There shall not be more than one part-ref with nonzero rank. A part-name to the right of a part-ref with nonzero rank shall not have the ALLOCATABLE or POINTER attribute.

So the most complicated it could get is something like

type :: t1
  integer :: vals(10)
end type
type :: t2
  type(t1) :: vals(15)
end type
type(t2), allocatable :: stuff(:)[:]

...
stuff(1:5:2)[n]%vals(2)%vals(3)

But I think that's still going to be well defined in terms of memory layout so the descriptor and coarray "handle" should still be sufficient.

[everythingfunctional]

I think this one still requires an extra operation to resolve the data location on the remote image though.

type :: t1
  integer :: vals(10)
end type
type :: t2
  type(t1), allocatable :: vals(:)
end type
type(t2), allocatable :: stuff[:]

...
stuff[n]%vals(2:10:2)%vals(3)

[everythingfunctional]

Just noticed this Note in the standard:

If the actual argument is a coindexed object, a processor that uses distributed memory might create a copy on the executing image of the actual argument, including copies of any allocated allocatable subobjects, and associate the dummy argument with that copy. If necessary, on return from the procedure, the value of the copy would be copied back to the actual argument.

[everythingfunctional]

Found another relevant statement in Section 11.6.2 Segments:

if a procedure invocation on image P is in execution in segments Pi , Pi+1, . . . , Pk and defines a noncoarray dummy argument, the effective argument shall not be referenced, defined, or become undefined on another image Q in a segment Qj unless Qj precedes Pi or succeeds Pk .