# Why cannot the Fortran coarray access an element in a different image? **URL:** \ **Category:** Help\ **Created:** [May 5, 2025, 4:15pm UTC](https://fortran-lang.discourse.group/t/why-cannot-the-fortran-coarray-access-an-element-in-a-different-image/9665 "2025-05-05T16:15:30Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![Shahid](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahid/32/3672_2.png) [@Shahid](https://fortran-lang.discourse.group/u/Shahid)\ **Post date:** [May 5, 2025, 4:15pm UTC](https://fortran-lang.discourse.group/t/why-cannot-the-fortran-coarray-access-an-element-in-a-different-image/9665/1 "2025-05-05T16:15:30Z")
My following coarray code does not show the expected output ```auto program caftest implicit none integer, dimension(5), codimension[*] :: a = 1 ! Image 1 a(1)[1] = 11 sync all ! Image 2 a(2)[2] = a(1)[1] sync all ! Only Image 1 prints if (this_image() == 1) then print*, 'a(2)[2] (Image 2 a(2)):', a(2)[2] ! Should be 11 print*, 'a(1)[1] (Image 1 a(1)):', a(1)[1] ! Should be 11 end if end program ``` output ```auto a(2)[2] (Image 2 a(2)): 1 a(1)[1] (Image 1 a(1)): 11 ``` However, modifying it provides the expected output ```auto program caftest implicit none integer, dimension(5), codimension[*] :: a = 1 ! Image 1 if (this_image() == 1) a(1) = 11 sync all ! Image 2 if (this_image() == 2) a(2) = a(1)[1] sync all ! Only Image 1 prints if (this_image() == 1) then print*, 'a(2)[2] (Image 2 a(2)):', a(2)[2] ! Should be 11 print*, 'a(1)[1] (Image 1 a(1)):', a(1)[1] ! Should be 11 end if end program ``` output ```auto a(2)[2] (Image 2 a(2)): 11 a(1)[1] (Image 1 a(1)): 11 ``` can’t we use the shorter version (first code) of accessing data among different images? I run the codes windows 10. ---
**Author:** ![nncarlson](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/nncarlson/32/1175_2.png) [@nncarlson](https://fortran-lang.discourse.group/u/nncarlson)\ **Post date:** [May 5, 2025, 9:18pm UTC](https://fortran-lang.discourse.group/t/why-cannot-the-fortran-coarray-access-an-element-in-a-different-image/9665/2 "2025-05-05T21:18:47Z")
What compiler are you using? Both the NAG and Intel compilers give the expected result with your original example. (Normally having all images write to the same location on the same image will create a race condition, but since they’re all writing the same value it doesn’t matter. But you’d never want to do that in practice.) ---
**Author:** ![Shahid](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahid/32/3672_2.png) [@Shahid](https://fortran-lang.discourse.group/u/Shahid)\ **Post date:** [May 6, 2025, 8:39am UTC](https://fortran-lang.discourse.group/t/why-cannot-the-fortran-coarray-access-an-element-in-a-different-image/9665/3 "2025-05-06T08:39:16Z")
I have not used intel compiler so far. I used the [Simply Fortran](https://simplyfortran.com/) IDE with Coarrays. It has gfortran compiler. ![Screenshot 2025-05-06 173531](https://global.discourse-cdn.com/free1/uploads/fortran_lang/original/2X/8/82fe6fa879bd4b4b69223792e358ce265ffe596e.png) ---
**Author:** ![themos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/themos/32/521_2.png) [@themos](https://fortran-lang.discourse.group/u/themos)\ **Post date:** [May 6, 2025, 9:16am UTC](https://fortran-lang.discourse.group/t/why-cannot-the-fortran-coarray-access-an-element-in-a-different-image/9665/4 "2025-05-06T09:16:56Z")
> [@nncarlson](#): > > Both the NAG and Intel compilers give the expected result with your original example. I suggest that there is no “expected result” because the code is invalid. The reason is as follows: The first segment of program CAFTEST consists of the statement ```auto a(1)[1] = 11 ``` There is no ordering imposed on that first segment executing on any of the images, in particular segment-1 executing on image-1 is unordered relative to segment-1 executing on image-2. 11.7.2 “Segments” (of J3/25-007) , para 3 lists the conditions for statements to be valid in unordered segments. None of the conditiions apply, and so we read ```auto • if a variable is defined or becomes undefined on an image in a segment, it shall not be referenced, defined, or become undefined in a segment on another image unless the segments are ordered, ``` This is an explicit injunction against “race conditions”. The program therefore has no meaning within the rules of Fortran, and there is no “expected result”. ---
**Author:** ![Shahid](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahid/32/3672_2.png) [@Shahid](https://fortran-lang.discourse.group/u/Shahid)\ **Post date:** [May 6, 2025, 10:27am UTC](https://fortran-lang.discourse.group/t/why-cannot-the-fortran-coarray-access-an-element-in-a-different-image/9665/5 "2025-05-06T10:27:36Z")
> [@themos](#): > > There is no ordering imposed What does ordering mean here and how to impose it? > [@themos](#): > > The first segment segment is another term new to me. Does assignment for coarray mean segment? ---
**Author:** ![themos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/themos/32/521_2.png) [@themos](https://fortran-lang.discourse.group/u/themos)\ **Post date:** [May 6, 2025, 11:31am UTC](https://fortran-lang.discourse.group/t/why-cannot-the-fortran-coarray-access-an-element-in-a-different-image/9665/6 "2025-05-06T11:31:54Z")
Segment ordering is the concept that the language definition develops in order to nail down what you expect the result to be and the conditions that must hold. You cannot analyse validity of coarray programs without knowing about segment ordering. I cannot reproduce what the Standard document says in my own words without making sloppy mistakes, you should consult a reputable book. In your example, a reasonable way to formulate what you intended is to use atomic intrinsic subroutines, I believe. ---
**Author:** ![jeff](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jeff/32/7201_2.png) [@jeff](https://fortran-lang.discourse.group/u/jeff)\ **Post date:** [May 6, 2025, 11:52am UTC](https://fortran-lang.discourse.group/t/why-cannot-the-fortran-coarray-access-an-element-in-a-different-image/9665/7 "2025-05-06T11:52:39Z")
> [@Shahid](#): > > I used the [Simply Fortran](https://simplyfortran.com/) IDE with Coarrays. It has gfortran compiler. Your original code also works using GNU Fortran + OpenCoarrays on macOS, so I think there is an issue in the [Simply Fortran Windows Coarray library](https://simplyfortran.com/blog/6/). I’m having a look at the internals right now to see where the problem lies. _EDIT:_ There appears to be an issue in our [\_gfortran\_caf\_sendget](https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gfortran/_005fgfortran_005fcaf_005fsendget.html) implementation, which is called on the line _a(2)[2] = a(1)[1]_. ---
**Author:** ![jeff](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jeff/32/7201_2.png) [@jeff](https://fortran-lang.discourse.group/u/jeff)\ **Post date:** [May 6, 2025, 6:07pm UTC](https://fortran-lang.discourse.group/t/why-cannot-the-fortran-coarray-access-an-element-in-a-different-image/9665/8 "2025-05-06T18:07:44Z")
It looks like our library, when handling a “sendget” (which is how GNU Fortran implements the `a(2)[2] = a(1)[1]` line) had some issues misidentifying a memory offset. Simply Fortran’s coarray implementation treats a “sendget” request as “get” requested foisted on another image. Effectively, all images are telling image 2 to get data from image 1. These messages are received by image 2, and it attempts to perform a “get” request as if it had originated from image 2. However, we had a memory issue reconstructing the “get” request where we were applying a memory offset to the source data rather than the destination data (since it is assigning it to the second element of image 2’s copy of the `a` array). There was another nasty problem related to retrieving the passed data’s array dimensions that I stumbled across debugging this simple example. We’ll get a bug-fix build out in the next day or two to correct the problems. ---
**Author:** ![themos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/themos/32/521_2.png) [@themos](https://fortran-lang.discourse.group/u/themos)\ **Post date:** [May 7, 2025, 8:43am UTC](https://fortran-lang.discourse.group/t/why-cannot-the-fortran-coarray-access-an-element-in-a-different-image/9665/9 "2025-05-07T08:43:50Z")
I am confused now. Are you aware, jeff, that the original code has no interpretation in Fortran? What interpretation are you using to “fix” the compiler? ---
**Author:** ![jeff](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jeff/32/7201_2.png) [@jeff](https://fortran-lang.discourse.group/u/jeff)\ **Post date:** [May 7, 2025, 11:32am UTC](https://fortran-lang.discourse.group/t/why-cannot-the-fortran-coarray-access-an-element-in-a-different-image/9665/10 "2025-05-07T11:32:14Z")
The correctness of the original code notwithstanding, this Fortran sample did reveal a bug in a coarray runtime library implementation. The output of GNU Fortran does make a call to a coarray library that was subsequently mishandled. I was merely pointing out that the output of the compiled code when linked with Simply Fortran’s coarray library was different from a case where the OpenCoarrays library was used, which should not have been the case and was revealed to be caused by a bug. ---
**Author:** ![themos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/themos/32/521_2.png) [@themos](https://fortran-lang.discourse.group/u/themos)\ **Post date:** [May 7, 2025, 1:29pm UTC](https://fortran-lang.discourse.group/t/why-cannot-the-fortran-coarray-access-an-element-in-a-different-image/9665/11 "2025-05-07T13:29:59Z")
Is it the case that the modified code, that does have an interpretation, and looks like ```auto ! Image 1 if (this_image() == 1) a(1) = 11 sync all ! Image 2 if (this_image() == 2) a(2) = a(1)[1] sync all ``` also reveals the bug? If you were to add a test case to catch any regressions of the bug, I hope it would be the modified, correct code. ---
**Author:** ![jeff](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jeff/32/7201_2.png) [@jeff](https://fortran-lang.discourse.group/u/jeff)\ **Post date:** [May 7, 2025, 4:11pm UTC](https://fortran-lang.discourse.group/t/why-cannot-the-fortran-coarray-access-an-element-in-a-different-image/9665/12 "2025-05-07T16:11:01Z")
No, your snippet would not exhibit the bug because the compiler will generate a [\_gfortran\_caf\_get](https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gfortran/_005fgfortran_005fcaf_005fget.html) call rather than the formerly problematic [\_gfortran\_caf\_sendget](https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gfortran/_005fgfortran_005fcaf_005fsendget.html) call. ---
**Author:** ![themos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/themos/32/521_2.png) [@themos](https://fortran-lang.discourse.group/u/themos)\ **Post date:** [May 7, 2025, 4:35pm UTC](https://fortran-lang.discourse.group/t/why-cannot-the-fortran-coarray-access-an-element-in-a-different-image/9665/13 "2025-05-07T16:35:30Z")
I think you should check correct operation of code generation for a correct program. Maybe ```auto ! Image 1 if (this_image() == 1) a(1) = 11 sync all ! Image 3 if (this_image() == 3) a(2)[2] = a(1)[1] sync all ``` would generate the [\_gfortran\_caf\_sendget](https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gfortran/_005fgfortran_005fcaf_005fsendget.html) that you seek? ---
**Author:** ![jeff](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jeff/32/7201_2.png) [@jeff](https://fortran-lang.discourse.group/u/jeff)\ **Post date:** [May 7, 2025, 4:39pm UTC](https://fortran-lang.discourse.group/t/why-cannot-the-fortran-coarray-access-an-element-in-a-different-image/9665/14 "2025-05-07T16:39:25Z")
Yep, that generates a `_gfortran_caf_sendget` and works after the fix.