Observed issues › nested/cce-fortran-nested-allocatable-component-copy-fault

Appears to behave incorrectlyCrashes or aborts at run time · Fortran · OpenMP · Changed in 21.0.3

CCE: nested allocatable component faults in copy mode

Legality: independently confirmed. One independent reading was uncertain; 2 adjudicating readings that weighed both find the program legal and the result required: The target region only references r, which is present from enter data; the structure-element restriction concerns map list items on the target construct, which has none. the fault is a compiler or runtime defect. How this is checked

CCE fails in copy mode on a derived type whose component is a derived type holding an allocatable array.

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	unknown not run	correct	correct	n/a	n/a
CCE 19.0.0	correct	behaves incorrectly	unknown not run	unknown not run	unknown not run	n/a	n/a
CCE 20.0.2	correct	behaves incorrectly	unknown not run	unknown not run	unknown not run	n/a	n/a
CCE 21.0.3	correct	fails another way	unknown not run	unknown not run	unknown not run	n/a	n/a
CCE 21.0.4	correct	fails another way	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	fails another way	correct
NVHPC 26.9	n/a	n/a	n/a	n/a	n/a	fails another way	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 copy	show Memory access fault by GPU node-6 (Agent handle: 0x4cac20) on address 0xe82000. Reason: Unknown.
behaves incorrectly	CCE 20.0.2, MI300A copy	show Memory access fault by GPU node-7 (Agent handle: 0x4c9ce0) on address 0x174b000. Reason: Unknown.
fails another way	CCE 21.0.3, MI300A copy CCE 21.0.4, MI300A copy	show ACC: libcrayacc/acc_hw_amd.c:1496 CRAY_ACC_ERROR - hipStreamSynchronize returned hipErrorIllegalAddress: 'an illegal memory access was encountered' from site-nested--cce-fortran-nested-allocatable-co ACC: libcrayacc/acc_hw_amd.c:1476 CRAY_ACC_ERROR - hipDeviceSynchronize returned hipErrorIllegalAddress: 'an illegal memory access was encountered'
fails another way	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:26 Line: 52

Reproduce

CCE 19.0.0, MI300A copy

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=0 OMP_TARGET_OFFLOAD=mandatory ./repro

CCE 20.0.2, MI300A copy

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=0 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 (57 lines)

! # Finding (nested-data): CCE, copy mode: a derived type with a derived-type component that holds an allocatable array, mapped
! # by enter data, makes the kernel fail
!
! - toolchains and modes that fail: cce19 (CCE 19.0.0), cce20 (CCE 20.0.2); modes: copy; -O2
! - build: ftn -fopenmp -O2
! - failure: crash
! - observed: `crash: SIGABRT; without mandatory: crash: SIGABRT` (killed by signal ABRT); identical signature on 2 of 2 failing
!   cells
! - expected: compiles and prints `tot= 1628` with `check=pass`
! - rule: a structure type has a predefined default mapper that maps its elements (OpenMP 5.2 §5.8.2 p.150 l.2-4: "A
!   structure type T has a predefined default mapper that is defined as if by a declare mapper directive that specifies
!   v in a map clause with the alloc map-type"), and the map clauses a mapper introduces are subject to the mappers in
!   scope (§5.8.8 p.164 l.1: "All map clauses that are introduced by a mapper are further subject to mappers that are in
!   scope"), so the default mapper of the component's derived type maps its allocatable array too; the program
!   references nothing else
! - same-compiler control: controls/n8-ctl-fixed-array-in-component.f90 (one change from this file; correct on cce19 (CCE 19.0.0),
!   cce20 (CCE 20.0.2); rows results/nested/red/tuo9.jsonl, results/nested/red/wgs.jsonl, results/nested/red/wnv.jsonl);
!   controls/n9-ctl-allocatable-in-the-variable.f90 (one change from this file; correct on cce19 (CCE 19.0.0), cce20 (CCE 20.0.2);
!   rows results/nested/red/tuo9.jsonl, results/nested/red/wgs.jsonl, results/nested/red/wnv.jsonl)
! - other families: afar (AFAR 24.3.0), cce21 (CCE 21.0.3), cce21_4 (CCE 21.0.4), nvhpc (NVHPC 25.11), nvhpc269 (NVHPC 26.9),
!   gcc_sm80 (GCC 16.2.0) run the file correctly in managed, unified mode (rows results/nested/red/tuo9.jsonl,
!   results/nested/red/wgs.jsonl, results/nested/red/wnv.jsonl); cce21 (CCE 21.0.3), cce21_4 (CCE 21.0.4), nvhpc (NVHPC 25.11),
!   nvhpc269 (NVHPC 26.9) fail it another way in copy mode, e.g. `exit_status: 1; without mandatory: exit_status: 1`
! - legality: the rules (offload.engine.rules) accept it; AFAR compiles and runs it correctly (a front end of another
!   family)
program t
  use omp_lib
  implicit none
  type :: n1
    integer, allocatable :: a(:)
  end type n1
  type :: n0
    type(n1) :: 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%a(8))
  do q = 1, 8
    r%nx%a(q) = 200 + q - 1
  end do
  tot = 0
  !$omp target enter data map(to: r)
  !$omp target teams distribute parallel do reduction(+: tot)
  do q = 1, 8
    tot = tot + r%nx%a(q)
  end do
  !$omp end target teams distribute parallel do
  !$omp target exit data map(release: r)
  ok = tot == 1628
  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

Memory access fault by GPU node-6 (Agent handle: 0x4cac20) on address 0xe82000. Reason: Unknown.

What the specification requires

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

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

A structure type T has a predefined default mapper that is defined as if by a declare mapper directive that specifies v in a map clause with the alloc map-type

OpenMP 5.2 §5.8.8 p.164 l.1

All map clauses that are introduced by a mapper are further subject to mappers that are in scope

Evidence

Same compiler, one change

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

Control program

! control: the component holds a fixed array
program t
  use omp_lib
  implicit none
  type :: n1
    integer :: a(8) = 0
  end type n1
  type :: n0
    type(n1) :: 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

  do q = 1, 8
    r%nx%a(q) = 200 + q - 1
  end do
  tot = 0
  !$omp target enter data map(to: r)
  !$omp target teams distribute parallel do reduction(+: tot)
  do q = 1, 8
    tot = tot + r%nx%a(q)
  end do
  !$omp end target teams distribute parallel do
  !$omp target exit data map(release: r)
  ok = tot == 1628
  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, cce20: not run yet

Control program

! control: the allocatable array in the variable itself
program t
  use omp_lib
  implicit none
  type :: n1
    integer :: s = 0
  end type n1
  type :: n0
    integer, allocatable :: a(:)
  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%a(8))
  do q = 1, 8
    r%a(q) = 200 + q - 1
  end do
  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)
  end do
  !$omp end target teams distribute parallel do
  !$omp target exit data map(release: r)
  ok = tot == 1628
  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, NVHPC 25.11, NVHPC 26.9, GCC 16.2.0