With a defaultmap clause on target, an explicitly mapped map(tofrom) scalar is not copied back, and with defaultmap(tofrom) an array in map(alloc) or map(to) is copied back

Legality: contested. An independent adjudicating reading finds the result not required: defaultmap(to: aggregate) is a valid implicit-behavior (a map type) and only affects implicitly mapped aggregates; x and a are explicitly mapped, so the program is conforming and race free. How this is checked

Affected variants

Compiler	MI300A gfx942 unified memory (XNACK 1)	MI300A gfx942 copy (XNACK 0)	MI250X gfx90a copy (XNACK 0)	MI300X gfx942 copy (XNACK 0)	MI350X gfx950 copy (XNACK 0)	A100 sm_80 separate memory	A100 sm_80 managed memory
AFAR 24.3.0	correct	correct	correct	correct	correct	n/a	n/a
CCE 19.0.0	correct	correct	correct	unknown not run	unknown not run	n/a	n/a
CCE 20.0.2	correct	correct	correct	unknown not run	unknown not run	n/a	n/a
CCE 21.0.3	behaves incorrectly	behaves incorrectly	behaves incorrectly	unknown not run	unknown not run	n/a	n/a
CCE 21.0.4	behaves incorrectly	behaves incorrectly	behaves incorrectly	unknown not run	unknown not run	n/a	n/a
NVHPC 25.11	n/a	n/a	n/a	n/a	n/a	correct	correct
NVHPC 26.9	n/a	n/a	n/a	n/a	n/a	correct	correct
GCC 16.2.0	correct	correct	correct	correct	correct	correct	n/a

"behaves incorrectly" / "not supported": this issue, confirmed in up to four environments (another build directory, another node, a repeat). "fails another way": a different failure, not counted as this issue. "unknown": not run there, or the runs disagree.

Messages

Result	Compiler and GPU	Message
behaves incorrectly	CCE 21.0.3, MI300A unified CCE 21.0.3, MI300A copy CCE 21.0.3, MI250X CCE 21.0.4, MI300A unified CCE 21.0.4, MI300A copy CCE 21.0.4, MI250X	show A 1 B 0 C 1

Reproduce

CCE 21.0.3, MI300A unified

module load cce/21.0.3 craype-accel-amd-gfx942 rocm/7.2.0
module unload cray-mpich
ftn -fopenmp -O2 repro.f90 -o repro
HSA_XNACK=1 OMP_TARGET_OFFLOAD=mandatory ./repro

CCE 21.0.4, MI300A unified

module load cce/21.0.4 craype-accel-amd-gfx942 rocm/7.2.0
module unload cray-mpich
ftn -fopenmp -O2 repro.f90 -o repro
HSA_XNACK=1 OMP_TARGET_OFFLOAD=mandatory ./repro

AFAR 24.3.0, MI300A unified (runs correctly)

$AFAR/bin/amdflang -fopenmp --offload-arch=gfx942 -O2 repro.f90 -o repro
HSA_XNACK=1 OMP_TARGET_OFFLOAD=mandatory ./repro

Program (45 lines)

! CCE 21: with a defaultmap clause on a target construct, the scalar x named
! in map(tofrom: x) is not copied back (a correction: the header
! this file did not have).
! Spec: x is explicitly mapped tofrom, which defaultmap does not change
! ("The defaultmap clause determines the implicit data-mapping or
! data-sharing attribute of certain variables that are referenced in a
! target construct", 5.2 §5.8.7 p.161 l.14-16), and on exit the original is
! updated "if the map-type is from or tofrom" (5.2 §5.8.3 p.154 l.2-5).
! Expected: A 0, B 0, C 0 (x = 0 from omp_is_initial_device() on the device).
! Observed: CCE 21.0.3 and 21.0.4: A 1, B 0, C 1, at HSA_XNACK 0 and 1, -O0
! and -O2. The region runs on the device: CRAY_ACC_DEBUG shows the kernel,
! and an array flag mapped from in the same region comes back 0 (vendor
! case cce21-defaultmap-device-probe); what is lost is the copy-back of x.
! Control: region B, the same construct without defaultmap: 0. CCE 19.0.0
! and 20.0.2: all zeros. The catalog's defaultmap programs read their
! ran_on_host flag through such a map(tofrom) scalar, so on CCE 21 they
! read ran_on_host=1 although they ran on the device (decided as this wrong
! answer: catalog/rulings.yaml RUL-MAPPED-FLAG-NOT-COPIED-BACK).
! CCE: ftn -fopenmp -O2 (module load cce/21.0.4 craype-accel-amd-gfx942
!      rocm/7.2.0; module unload cray-mpich)
program h
  use omp_lib
  implicit none
  integer :: x, i
  integer, allocatable :: a(:)
  allocate(a(8)); a=1
  x=1
  !$omp target map(tofrom:x) map(to:a) defaultmap(to: aggregate)
  x = merge(1,0,omp_is_initial_device())
  !$omp end target
  print *, 'A', x
  x=1
  !$omp target map(tofrom:x) map(to:a)
  x = merge(1,0,omp_is_initial_device())
  !$omp end target
  print *, 'B', x
  x=1
  !$omp target map(tofrom:x) map(to:a) defaultmap(to: aggregate)
  x = merge(1,0,omp_is_initial_device())
  do i=1,8
    a(i)=2
  end do
  !$omp end target
  print *, 'C', x
end

Source in the repository

Something to add? Dispute its legality · Report it fixed in a newer release · Report a mistake on this page

Expected and observed

Expected

A 0 B 0 C 0

Observed where it behaves incorrectly

 A 1
 B 0
 C 1

What the specification requires

The specification text this program relies on and the compiler is expected to support.

OpenMP 5.2 §5.8.7 p.161 l.14-16

The defaultmap clause determines the implicit data-mapping or data-sharing attribute of certain variables that are referenced in a target construct

OpenMP 5.2 §5.8.3 p.154 l.2-5

if the map-type is from or tofrom

Evidence

Same compiler, one change

defaultmap(to: aggregate) removed from regions A and C: AFAR 24.3.0: correct; CCE 19.0.0: correct; CCE 20.0.2: correct; CCE 21.0.3: correct; CCE 21.0.4: correct

Control program

program h
  use omp_lib
  implicit none
  integer :: x, i
  integer, allocatable :: a(:)
  allocate(a(8)); a=1
  x=1
  !$omp target map(tofrom:x) map(to:a)
  x = merge(1,0,omp_is_initial_device())
  !$omp end target
  print *, 'A', x
  x=1
  !$omp target map(tofrom:x) map(to:a)
  x = merge(1,0,omp_is_initial_device())
  !$omp end target
  print *, 'B', x
  x=1
  !$omp target map(tofrom:x) map(to:a)
  x = merge(1,0,omp_is_initial_device())
  do i=1,8
    a(i)=2
  end do
  !$omp end target
  print *, 'C', x
end

Other compilers run it correctly

AFAR 24.3.0, NVHPC 25.11, NVHPC 26.9, GCC 16.2.0