Observed issues › nested/cce-fortran-update-to-pointer-root-allocatable-scalar-component-no-accelerator-object

Appears to behave incorrectlyRun-time error · Fortran · OpenMP · Open

CCE: update to of a pointer root with an allocatable scalar component fails

Legality: contested. An independent adjudicating reading finds the result not required: map(alloc: r) of an associated pointer maps its target as if implicitly mapped. The default-mapper rule for components says an allocatable component that is not an explicit list item may be treated as unallocated if the corresponding component lacks allocated storage. Whether target update to(r) transfers the pointer target and the allocatable component nx is not stated. How this is checked

CCE stops at target update to() of a pointer root with an allocatable scalar component.

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	fails another way	unknown not run	fails another way	fails another way	n/a	n/a
CCE 19.0.0	behaves incorrectly	behaves incorrectly	unknown not run	unknown not run	unknown not run	n/a	n/a
CCE 20.0.2	behaves incorrectly	behaves incorrectly	unknown not run	unknown not run	unknown not run	n/a	n/a
CCE 21.0.3	behaves incorrectly	behaves incorrectly	unknown not run	unknown not run	unknown not run	n/a	n/a
CCE 21.0.4	behaves incorrectly	behaves incorrectly	unknown not run	unknown not run	unknown not run	n/a	n/a
NVHPC 25.11	n/a	n/a	n/a	n/a	n/a	behaves incorrectly	correct
NVHPC 26.9	n/a	n/a	n/a	n/a	n/a	behaves incorrectly	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 19.0.0, MI300A unified CCE 19.0.0, MI300A copy	show ACC: libcrayacc/acc_datatype.c:1236 CRAY_ACC_ERROR - host object 0x40a5c0 does not appear to have an associated accelerator object.
behaves incorrectly	CCE 20.0.2, MI300A unified CCE 20.0.2, MI300A copy	show ACC: libcrayacc/acc_datatype.c:1236 CRAY_ACC_ERROR - host object 0x4095c0 does not appear to have an associated accelerator object.
behaves incorrectly	CCE 21.0.3, MI300A unified CCE 21.0.3, MI300A copy CCE 21.0.4, MI300A unified CCE 21.0.4, MI300A copy	show ACC: libcrayacc/acc_datatype.c:1236 CRAY_ACC_ERROR - host object 0x409a80 does not appear to have an associated accelerator object.
behaves incorrectly	NVHPC 25.11, A100 separate NVHPC 26.9, A100 separate	show Failing in Thread:1 Accelerator Fatal Error: call to cuMemcpyDtoHAsync returned error 700 (CUDA_ERROR_ILLEGAL_ADDRESS): Illegal address during kernel execution File: <dir> Function: t:37 Line: 68
fails another way	AFAR 24.3.0, MI300A copy	show Warning: Queue error - HSA_STATUS_ERROR_MEMORY_FAULT Display last 2 kernels launched: Kernel 0: 'omp target in _QQmain @ 64 (__omp_offloading_14_37cbd86__QQmain_l64)' Kernel 1: 'omp target in _QQmain @ 52 (__omp_offloading_14_37cbd86__QQmain_l52)' Use 'OFFLOAD_TRACK_NUM_KERNEL_LAUNCH_TRACES=<num>' to adjust the number of shown stack traces (0 now, up to 8) OFFLOAD ERROR: memory access fault by GPU 5 (agent 0x5555556e4f80) at virtual address 0x555555b5a000. Reasons: Unknown (0) Use 'OFFLOAD_TRACK_ALLOCATION_TRACES=true' to track device allocations
fails another way	AFAR 24.3.0, MI300X	show Warning: Queue error - HSA_STATUS_ERROR_MEMORY_FAULT Display last 2 kernels launched: Kernel 0: 'omp target in _QQmain @ 64 (__omp_offloading_fc10_60434d2__QQmain_l64)' Kernel 1: 'omp target in _QQmain @ 52 (__omp_offloading_fc10_60434d2__QQmain_l52)' Use 'OFFLOAD_TRACK_NUM_KERNEL_LAUNCH_TRACES=<num>' to adjust the number of shown stack traces (0 now, up to 8) OFFLOAD ERROR: memory access fault by GPU 1 (agent 0x5568b6075790) at virtual address 0x5568b61f9000. Reasons: Unknown (0) Use 'OFFLOAD_TRACK_ALLOCATION_TRACES=true' to track device allocations timeout: the monitored command dumped core
fails another way	AFAR 24.3.0, MI350X	show Warning: Queue error - HSA_STATUS_ERROR_MEMORY_FAULT Display last 2 kernels launched: Kernel 0: 'omp target in _QQmain @ 64 (__omp_offloading_fc10_4174d8b__QQmain_l64)' Kernel 1: 'omp target in _QQmain @ 52 (__omp_offloading_fc10_4174d8b__QQmain_l52)' Use 'OFFLOAD_TRACK_NUM_KERNEL_LAUNCH_TRACES=<num>' to adjust the number of shown stack traces (0 now, up to 8) OFFLOAD ERROR: memory access fault by GPU 1 (agent 0x561c22749d10) at virtual address 0x561c228b4000. Reasons: Unknown (0) Use 'OFFLOAD_TRACK_ALLOCATION_TRACES=true' to track device allocations timeout: the monitored command dumped core

Reproduce

CCE 19.0.0, MI300A unified

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

CCE 20.0.2, MI300A unified

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

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

NVHPC 25.11, A100 separate

export LD_LIBRARY_PATH=$NVHPC_25_11/compilers/lib
nvfortran -mp=gpu -gpu=cc80 -gpu=mem:separate -O2 repro.f90 -o repro
OMP_TARGET_OFFLOAD=mandatory ./repro

NVHPC 26.9, A100 separate

export LD_LIBRARY_PATH=$NVHPC_26_9/compilers/lib
nvfortran -mp=gpu -gpu=cc80 -gpu=mem:separate -O2 repro.f90 -o repro
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 (73 lines)

! # Finding (nested-data): CCE: target update to() of a pointer to a derived type with an allocatable scalar component, entered
! # with map(alloc:), fails: "host object does not appear to have an associated accelerator object"
!
! - toolchains and modes that fail: cce19 (CCE 19.0.0), cce21_4 (CCE 21.0.4); modes: unified, copy; -O2
! - build: ftn -fopenmp -O2
! - failure: run_error
! - observed: `exit_status: 1; without mandatory: exit_status: 1`; identical signature on 4 of 4 failing cells
! - expected: compiles and prints `tot= 996` with `check=pass`
! - rule: a list item with an allocatable subobject is updated only if the subobject is allocated (OpenMP 5.2 §5.9 p.165
!   l.28-29: "If a list item or a subobject of a list item has the ALLOCATABLE attribute, its assignment is performed
!   only if its allocation status is allocated"); the structure was entered with map(alloc: r), whose default mapper
!   maps the allocated component (§5.8.2 p.150 l.2-4), so the update has a device copy to write
! - same-compiler control: controls/ua2-ctl-variable-root.f90 (one change from this file; correct on cce19 (CCE 19.0.0), cce21_4
!   (CCE 21.0.4); rows results/nested/red/tuo21.jsonl, results/nested/red/wgs5.jsonl, results/nested/red/wnv5.jsonl);
!   controls/ua4-ctl-to-in-place-of-alloc-and-update.f90 (one change from this file; correct on cce19 (CCE 19.0.0), cce21_4 (CCE
!   21.0.4); rows results/nested/red/tuo21.jsonl, results/nested/red/wgs5.jsonl, results/nested/red/wnv5.jsonl)
! - other families: nvhpc (NVHPC 25.11), nvhpc269 (NVHPC 26.9), gcc_sm80 (GCC 16.2.0) run the file correctly in managed mode (rows
!   results/nested/red/wgs5.jsonl, results/nested/red/wnv5.jsonl); nvhpc (NVHPC 25.11), nvhpc269 (NVHPC 26.9) fail the controls too,
!   so a failure with this signature is not claimed to be this one; afar (AFAR 24.3.0) fail it another way, e.g. `crash: SIGABRT;
!   without mandatory: crash: SIGABRT` (killed by signal ABRT)
! - gate and confirmer: campaign gate of the programs below: 48 cells, 47 confirmed in the four environments (a-d; (c) on another
!   node or GPU; rows results/nested/big/gate_reruns.part.<host>.3222831.jsonl,
!   results/nested/big/gate_reruns.part.<host>.1040717.jsonl, results/nested/big/gate_reruns.part.<host>.1284552.jsonl,
!   results/nested/big/gate_reruns.part.<host>.1251749.jsonl, results/nested/big/gate_reruns.part.<host>.1517583.jsonl,
!   results/nested/big/gate_reruns.part.<host>.1434668.jsonl, results/nested/big/rows.part.<host>.1956389.jsonl,
!   results/nested/big/rows.part.<host>.1523848.jsonl, results/nested/big/rows.part.<host>.1239313.jsonl,
!   results/nested/big/rows.part.<host>.1197409.jsonl, results/nested/big/rows.part.<host>.1146311.jsonl,
!   results/nested/main/gate_reruns.part.<host>.961942.jsonl, results/nested/main/gate_reruns.part.<host>.919396.jsonl,
!   results/nested/main/gate_reruns.part.<host>.3910568.jsonl,
!   results/nested/main/gate_reruns.part.<host>.4072524.jsonl, results/nested/main/rows.part.<host>.994167.jsonl)
! - programs (12): nd-f-omp-update-chain-d1-222d392b, nd-f-omp-update-chain-d1-eb999367, nd-f-omp-update-chain-d2-018eb6d9,
!   nd-f-omp-update-chain-d2-3daf06e5, nd-f-omp-update-chain-d2-75e83840, nd-f-omp-update-chain-d2-9756b365,
!   nd-f-omp-update-chain-d2-d90fc1ec, nd-f-omp-update-chain-d2-eb4cf5ae, nd-f-omp-update-chain-d3-3d5ca029,
!   nd-f-omp-update-chain-d3-cf66ca90, nd-f-omp-update-chain-d3-f84ee81c, nd-f-omp-update-tree-d3-cef9276d
! - legality: the rules (offload.engine.rules) accept it; AFAR compiles it (a front end of another family; AFAR fails the
!   pointer-root shape at run time for its own reason, which its map(to:) control shares)
program t
  use omp_lib
  implicit none
  type :: n1
    integer :: s = 0
  end type n1
  type :: n0
    integer :: s = 0
    integer :: a(8) = 0
    type(n1), allocatable :: nx
  end type n0
  type(n0), pointer :: r
  integer :: q, hf, tot
  logical :: ok
  hf = 1
  !$omp target map(from: hf)
  hf = merge(1, 0, omp_is_initial_device())
  !$omp end target
  allocate(r)
  allocate(r%nx)
  do q = 1, 8
    r%a(q) = 100 + q - 1
  end do
  r%nx%s = 21
  tot = 0
  !$omp target enter data map(alloc: r)
  !$omp target update to(r)
  !$omp target teams distribute parallel do reduction(+: tot)
  do q = 1, 8
    tot = tot + r%a(q) + r%nx%s
  end do
  !$omp end target teams distribute parallel do
  !$omp target exit data map(delete: r)
  ok = tot == 996
  print '(a,i0)', 'tot= ', tot
  print '(a,i0,a,a)', 'RESULT ran_on_host=', hf, ' check=', merge('pass', 'fail', ok)
end program t

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

Observed where it behaves incorrectly

ACC: libcrayacc/acc_datatype.c:1236 CRAY_ACC_ERROR - host object 0x40a5c0 does not appear to have an associated accelerator object.

What the specification requires

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

OpenMP 5.2 §5.9 p.165 l.28-29

If a list item or a subobject of a list item has the ALLOCATABLE attribute, its assignment is performed only if its allocation status is allocated

OpenMP 5.2 §5.8.2 p.150 l.2-4

Evidence

Same compiler, one change

one change from the finding; correct on cce19, cce21_4: not run yet

Control program

! control: the root is a variable, not a pointer
program t
  use omp_lib
  implicit none
  type :: n1
    integer :: s = 0
  end type n1
  type :: n0
    integer :: s = 0
    integer :: a(8) = 0
    type(n1), allocatable :: nx
  end type n0
  type(n0) :: r
  integer :: q, hf, tot
  logical :: ok
  hf = 1
  !$omp target map(from: hf)
  hf = merge(1, 0, omp_is_initial_device())
  !$omp end target
  allocate(r%nx)
  do q = 1, 8
    r%a(q) = 100 + q - 1
  end do
  r%nx%s = 21
  tot = 0
  !$omp target enter data map(alloc: r)
  !$omp target update to(r)
  !$omp target teams distribute parallel do reduction(+: tot)
  do q = 1, 8
    tot = tot + r%a(q) + r%nx%s
  end do
  !$omp end target teams distribute parallel do
  !$omp target exit data map(delete: r)
  ok = tot == 996
  print '(a,i0)', 'tot= ', tot
  print '(a,i0,a,a)', 'RESULT ran_on_host=', hf, ' check=', merge('pass', 'fail', ok)
end program t

one change from the finding; correct on cce19, cce21_4: not run yet

Control program

! control: enter data map(to: r) in place of map(alloc: r) and the update
program t
  use omp_lib
  implicit none
  type :: n1
    integer :: s = 0
  end type n1
  type :: n0
    integer :: s = 0
    integer :: a(8) = 0
    type(n1), allocatable :: nx
  end type n0
  type(n0), pointer :: r
  integer :: q, hf, tot
  logical :: ok
  hf = 1
  !$omp target map(from: hf)
  hf = merge(1, 0, omp_is_initial_device())
  !$omp end target
  allocate(r)
  allocate(r%nx)
  do q = 1, 8
    r%a(q) = 100 + q - 1
  end do
  r%nx%s = 21
  tot = 0
  !$omp target enter data map(to: r)
  !$omp target teams distribute parallel do reduction(+: tot)
  do q = 1, 8
    tot = tot + r%a(q) + r%nx%s
  end do
  !$omp end target teams distribute parallel do
  !$omp target exit data map(delete: r)
  ok = tot == 996
  print '(a,i0)', 'tot= ', tot
  print '(a,i0,a,a)', 'RESULT ran_on_host=', hf, ' check=', merge('pass', 'fail', ok)
end program t

Other compilers run it correctly

AFAR 24.3.0, GCC 16.2.0