> Gesendet: Samstag, 26. Juli 2025 um 19:03
> Von: "Harald Anlauf" <[email protected]>
> An: [email protected], [email protected]
> CC: [email protected]
> Betreff: Re: Aw: Re: Add: [Bug fortran/121043] [16 Regression] Tests of
> OpenCoarray fail to pass, works on 15.1.1 20250712
> > The function get_val() returns the current image, so when assigning to
> > res(get_val())[1], it should be evaluated on the local image, otherwise
> > only the first element of res is populated (and with conflicting values).
>
> What is important is what the standard says. In the above code,
> the array index is to be evalutated before the assignment takes place.
> The following thus should be equvivalent:
>
> res(img)[1] = data
> res(get_val())[1] = data
> res(this_image())[1] = data
>
> Which are all the caf equivalent of mpi_gather with communicator
> mpi_comm_world
> and root=0 (= image 1). Confirmed with NAG and ifx
I may be wrong with assumptions on how often the array index is to be
evalutated.
The following variation with an impure function behaves differently with NAG
and ifx:
program p
implicit none
integer :: img, data
integer :: cnt[*] = 0
integer, allocatable :: res(:)[:]
img = this_image()
data = img * img + 10 ! Something different on each image
allocate(res(num_images())[*], source=-1)
res(get_val())[1] = data
sync all
if (this_image() == 1) print *, res
sync all
res(this_image())[1] = cnt
sync all
if (this_image() == 1) print *, res
contains
function get_val()
integer :: get_val
get_val = img
cnt = cnt + 1 ! Count invocations of get_val
end function
end program
My naive expectation is that the final print gives all 1's,
which is the case with NAG, but not with ifx.
So is there a requirement in the standard that function references
in array index computations must be pure? Otherwise ifx has a bug here.
> > Andre, Harald, is this the original topic of this thread?
> > Is my reasoning correct?
>
> Yes and no. Your example has only the initial team with the associated
> communicator (this is my layman's interpretation).
>
> Andre's testcase in addition uses teams in ways I do not yet understand.
>
> Harald
>