Fortran 2008 Coarray Default Synchronization: Unresolved Implicit Sync Behavior

The direct answer

The Fortran 2008 standard (ISO/IEC 1539-1:2010, Clause 8.5) does not mandate implicit synchronization for coarray references, and — contrary to the premise in the question — no current production compiler inserts an implicit barrier on each coarray access. A reference such as a[2] is an ordinary memory operation against another image's storage; it is not an image control statement, and a conforming implementation adds no ordering around it. The portability worry described in the question is therefore not a real divergence between vendors: the race conditions come from omitted synchronization in the source code, not from differing compiler policies.

What the standard actually specifies

Fortran 2008 defines execution on each image as a sequence of segments. Segment boundaries are created only by explicit image control statements:

• SYNC ALL, SYNC IMAGES, SYNC MEMORY
• LOCK / UNLOCK on lock variables
• CRITICAL / END CRITICAL
• Collective subroutines such as CO_BROADCAST, CO_SUM, CO_REDUCE
• ALLOCATE/DEALLOCATE of a coarray, and image termination

Ordering between images exists only across matching segment boundaries. Within a segment, coarray reads and writes on different images are unordered, and the compiler is even permitted to reorder independent coarray accesses. So a plain real :: a[*] read or write carries no synchronization semantics whatsoever, by design.

Compiler behavior in practice

GNU gfortran (with -fcoarray=lib backed by OpenCoarrays), Intel ifort/ifx (-coarray), NAG, Cray/HPE, and Fujitsu all implement the standard model: synchronization is explicit only. If code appears to "work" on one compiler and fail on another, the usual cause is timing luck — one build happened to schedule images so the unsynchronized access usually landed after the write — not an implicit barrier. Early coarray implementations (gfortran 4.6–4.7, first Intel releases) had genuine synchronization bugs, so use a current release before drawing conclusions.

The portable pattern

For a producer/consumer pair, both sides must synchronize:

if (this_image() == 1) then
  a[2] = computed_value       ! write remote data
  sync images(2)              ! signal: data ready
else if (this_image() == 2) then
  sync images(1)              ! wait for image 1's segment
  local = a[2]                ! now ordered after the write
end if

Prefer SYNC IMAGES with an explicit image set over SYNC ALL for point-to-point patterns — SYNC ALL is a global barrier and hurts scalability. If you use ATOMIC_DEFINE/ATOMIC_REF without any other image control statement, add SYNC MEMORY to order surrounding non-atomic accesses. Fortran 2018's EVENT_TYPE with EVENT POST/EVENT WAIT gives lighter-weight point-to-point signaling where available.

Documenting and enforcing semantics

• State the synchronization contract in the procedure header: e.g., "caller must have executed SYNC IMAGES with this image before entry." A coarray dummy argument cannot be assumed synchronized on entry.
• Keep each remote write and its matching sync adjacent in source so the segment structure is visible during review.
• Verify with a minimal two-image test: image 1 writes a coarray with no sync, image 2 reads immediately. On any conforming compiler the result is non-deterministic; adding the paired SYNC IMAGES makes it deterministic. Run it under both gfortran and ifx to confirm identical behavior.

One caveat worth flagging: pre-standard coarray dialects (Cray pointers, CAF 1.0) had their own varying semantics. If inherited code predates Fortran 2008 conformance, audit it rather than assuming the modern rules were followed.