> Gesendet: Samstag, 26. Juli 2025 um 19:03
> Von: "Harald Anlauf" <anl...@gmx.de>
> An: morin-mik...@orange.fr, ve...@gmx.de
> CC: fortran@gcc.gnu.org
> 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
> 

Reply via email to