offtarget 0.1.0__py3-none-any.whl

offload/_root/data/findings/oop/cce-copy-alloc-component-section-fault.f90

@@ -0,0 +1,73 @@
+! # Finding (fortran-oop): map(tofrom: x%a(9:40)) of an allocatable component section faults on the device in copy mode
+!
+! - toolchains and modes that fail: cce19 (CCE 19.0.0: copy), cce20 (CCE 20.0.2: copy), cce21 (CCE 21.0.3: copy), cce21_4 (CCE
+!   21.0.4: copy); -O2
+! - build: ftn -fopenmp -O2 (module load cce/<v> craype-accel-amd-gfx942 rocm/<r>; OpenACC: ftn -h acc)
+! - failure: crash / run_error; OMP_TARGET_OFFLOAD=mandatory
+! - observed: HSA_XNACK=0: CCE 19 and 20 `Memory access fault by GPU ... on address (nil)` (SIGABRT); CCE 21.0.3 and 21.0.4
+!   `hipStreamSynchronize returned hipErrorIllegalAddress` (exit 1); HSA_XNACK=1 correct. Also a section of an allocatable
+!   component of a nested structure and of an allocatable array-of-structures component of an allocatable scalar
+! - expected: `r1= 34080 r2= 8`
+! - rule: 5.2 §5.8.3 p.151 l.13 (structure elements and array sections are list items); the region references only the mapped
+!   elements (§5.8.3 p.157 l.21-22)
+! - same-compiler control: the same program mapping the whole component (controls/section-alloc-whole-component.f90, one change):
+!   correct (check=pass) on CCE 19, 20, 21.0.3 and 21.0.4 in both modes, in the stored run and the gate's four environments a-d
+!   with (c) on another node (results/oop/probe/ctl2.*.section-alloc-whole-component.*.jsonl)
+! - other families: AFAR and GCC 16.2 correct; the AOMP fortran-map-tests leads of harvest 2
+!   (dtype-allocatable-array-with-bounds-map, nested-dtype-allocatable-array-with-bounds-map, dtype-array-of-dtype-member-map-v5)
+!   also fail on CCE
+! - gate and confirmer: 12 cells, 12 confirmed in the gate's four environments (a-d; results/oop/main/gate_reruns*.jsonl);
+!   confirmer (results/oop/main/confirm.jsonl): needs_human (R22-expected-weak) 12; R22-expected-weak means the expected value has
+!   one source, the generator's Python model; the values follow from the program's arithmetic (checked by hand), and AFAR, GCC
+!   16.2 (gfx90a), GCC 16.2 (sm_80), NVHPC 25.11, NVHPC 26.9 print them on this program
+! - programs (3): oop-section-alloc, oop-section-nested, oop-elemsec-alloc-parent (offload/engine/oop_gen.py; this file is the first
+!   one)
+! - legality: for the cce cells: the rules (offload.engine.rules, with the fortran-oop restrictions) and AFAR's flang front end
+!   (-fsyntax-only) and NVHPC 26.9 nvfortran (compile only) (tools/campaigns/oop.py legality, results/oop/main/legality.json)
+module oop_m
+  implicit none
+  integer, parameter :: n = 64
+  type vec
+    integer :: n = 0
+    integer, allocatable :: a(:)
+  end type vec
+end module oop_m
+
+program oop
+  use omp_lib
+  use oop_m
+  implicit none
+  integer :: host_flag
+  logical :: ok
+  integer :: r1, r2
+  type(vec) :: x
+  integer :: i
+  host_flag = 1
+  !$omp target map(from: host_flag)
+  host_flag = merge(1, 0, omp_is_initial_device())
+  !$omp end target
+  allocate(x%a(n))
+  x%n = n
+  do i = 1, n
+    x%a(i) = i
+  end do
+  !$omp target teams distribute parallel do map(tofrom: x%a(9:40))
+  do i = 9, 40
+    x%a(i) = x%a(i) + 1000
+  end do
+  r1 = sum(x%a)
+  r2 = x%a(8)
+  ok = .true.
+  ok = ok .and. (r1 == 34080)
+  ok = ok .and. (r2 == 8)
+  print '(a,i0)', 'r1= ', r1
+  print '(a,i0)', 'r2= ', r2
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', ok)
+end program oop
+! site:
+! title: mapping a section of an allocatable component faults on the GPU with separate memory
+! summary: map(tofrom: x%a(9:40)), a section of an allocatable array component, on a target teams distribute parallel do faults on
+! + the GPU (memory access fault, illegal address) with CCE 19, 20 and 21 when host and device memory are separate. Mapping the
+! + whole component works; unified memory works.
+! control: oop/controls/section-alloc-whole-component.f90 the same program; the whole component x%a instead of the section
+! end site

offload/_root/data/findings/oop/cce-copy-parent-to-component-tofrom-lost.f90

@@ -0,0 +1,65 @@
+! # Finding (fortran-oop): map(to: x) map(tofrom: x%a): the allocatable component is not copied back (copy mode)
+!
+! - toolchains and modes that fail: cce19 (CCE 19.0.0: copy), cce20 (CCE 20.0.2: copy), cce21 (CCE 21.0.3: copy), cce21_4 (CCE
+!   21.0.4: copy); -O2
+! - build: ftn -fopenmp -O2 (module load cce/<v> craype-accel-amd-gfx942 rocm/<r>; OpenACC: ftn -h acc)
+! - failure: wrong_answer (check=fail); OMP_TARGET_OFFLOAD=mandatory
+! - observed: `r1= 2080` (the host values) at HSA_XNACK=0 on every CCE release; HSA_XNACK=1 correct
+! - expected: `r1= 2528`
+! - rule: 5.2 §5.8.3 p.156 l.6-7 (a structure and its element may both be list items); the component is mapped tofrom, so it is
+!   copied back on exit (§5.8.3 p.154 exit step 1a)
+! - same-compiler control: the same program without map(to: x) (controls/parent-and-comp-component-only.f90, one change): correct
+!   (check=pass) on CCE 19, 20, 21.0.3 and 21.0.4 in both modes, in the stored run and the gate's four environments a-d with (c)
+!   on another node (results/oop/probe/ctl2.*.parent-and-comp-component-only.*.jsonl)
+! - other families: AFAR and GCC 16.2 correct
+! - gate and confirmer: 4 cells, 4 confirmed in the gate's four environments (a-d; results/oop/main/gate_reruns*.jsonl); confirmer
+!   (results/oop/main/confirm.jsonl): needs_human (R22-expected-weak) 4; R22-expected-weak means the expected value has one
+!   source, the generator's Python model; the values follow from the program's arithmetic (checked by hand), and AFAR, GCC 16.2
+!   (gfx90a), GCC 16.2 (sm_80), NVHPC 25.11, NVHPC 26.9 print them on this program
+! - programs (1): oop-alloccomp-parent-and-comp (offload/engine/oop_gen.py; this file is the first one)
+! - legality: for the cce cells: the rules (offload.engine.rules, with the fortran-oop restrictions) and AFAR's flang front end
+!   (-fsyntax-only) and NVHPC 26.9 nvfortran (compile only) (tools/campaigns/oop.py legality, results/oop/main/legality.json)
+module oop_m
+  implicit none
+  integer, parameter :: n = 64
+  type vec
+    integer :: n = 0
+    integer, allocatable :: a(:)
+  end type vec
+end module oop_m
+
+program oop
+  use omp_lib
+  use oop_m
+  implicit none
+  integer :: host_flag
+  logical :: ok
+  integer :: r1
+  type(vec) :: x
+  integer :: i
+  host_flag = 1
+  !$omp target map(from: host_flag)
+  host_flag = merge(1, 0, omp_is_initial_device())
+  !$omp end target
+  allocate(x%a(n))
+  x%n = n
+  do i = 1, n
+    x%a(i) = i
+  end do
+  !$omp target teams distribute parallel do map(to: x) map(tofrom: x%a)
+  do i = 1, n
+    x%a(i) = x%a(i) + 7
+  end do
+  r1 = sum(x%a)
+  ok = .true.
+  ok = ok .and. (r1 == 2528)
+  print '(a,i0)', 'r1= ', r1
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', ok)
+end program oop
+! site:
+! title: map(to: x) with map(tofrom: x%a) loses the component's copy back
+! summary: With map(to: x) map(tofrom: x%a) on one target construct (x a structure with an allocatable array component a), the
+! + device's writes to x%a do not come back to the host with CCE 19, 20 and 21 when memory is separate. Mapping x%a alone works.
+! + AFAR and GCC are correct.
+! control: oop/controls/parent-and-comp-component-only.f90 the same program without map(to: x)
+! end site

offload/_root/data/findings/oop/cce-copy-second-member-section-lost.f90

@@ -0,0 +1,65 @@
+! # Finding (fortran-oop): two member sections of one structure on one map clause: the second is not copied back (copy mode)
+!
+! - toolchains and modes that fail: cce19 (CCE 19.0.0: copy), cce20 (CCE 20.0.2: copy), cce21 (CCE 21.0.3: copy), cce21_4 (CCE
+!   21.0.4: copy); -O2
+! - build: ftn -fopenmp -O2 (module load cce/<v> craype-accel-amd-gfx942 rocm/<r>; OpenACC: ftn -h acc)
+! - failure: wrong_answer (check=fail); OMP_TARGET_OFFLOAD=mandatory
+! - observed: `r1= 18 r2= 0` at HSA_XNACK=0 on every CCE release: f%b(3:6) comes back, f%d(3:6) does not; with two structures the
+!   second member of each is lost (`r1= 18 r2= 54`, expected 54 126); HSA_XNACK=1 correct
+! - expected: `r1= 18 r2= 36`
+! - rule: 5.2 §5.8.3 p.152 l.28-31 (list items with the same containing structure form one mappable storage block); §5.8.3 p.154
+!   exit step 1a (each tofrom list item is copied back); §13.8 p.286 l.27-28 (every referenced element is mapped)
+! - same-compiler control: one member section (controls/section-fixed.f90): correct on every CCE in both modes
+!   (results/oop/main/rows.part*.jsonl)
+! - other families: AFAR and GCC 16.2 correct; the AOMP leads derived-type-member-array-map-3 and
+!   double-derived-type-double-member-array-map also fail on CCE
+! - gate and confirmer: 8 cells, 8 confirmed in the gate's four environments (a-d; results/oop/main/gate_reruns*.jsonl); confirmer
+!   (results/oop/main/confirm.jsonl): needs_human (R22-expected-weak) 8; R22-expected-weak means the expected value has one
+!   source, the generator's Python model; the values follow from the program's arithmetic (checked by hand), and AFAR, GCC 16.2
+!   (gfx90a), GCC 16.2 (sm_80), NVHPC 25.11, NVHPC 26.9 print them on this program
+! - programs (2): oop-elemsec-two-members, oop-elemsec-two-structs (offload/engine/oop_gen.py; this file is the first one)
+! - legality: for the cce cells: the rules (offload.engine.rules, with the fortran-oop restrictions) and AFAR's flang front end
+!   (-fsyntax-only) and NVHPC 26.9 nvfortran (compile only) (tools/campaigns/oop.py legality, results/oop/main/legality.json)
+module oop_m
+  implicit none
+  integer, parameter :: n = 64
+  type da
+    integer :: b(10) = 0
+    integer :: d(10) = 0
+  end type da
+end module oop_m
+
+program oop
+  use omp_lib
+  use oop_m
+  implicit none
+  integer :: host_flag
+  logical :: ok
+  integer :: r1, r2
+  type(da) :: f
+  integer :: l
+  host_flag = 1
+  !$omp target map(from: host_flag)
+  host_flag = merge(1, 0, omp_is_initial_device())
+  !$omp end target
+  !$omp target map(tofrom: f%b(3:6), f%d(3:6))
+  do l = 3, 6
+    f%b(l) = l
+    f%d(l) = 2 * l
+  end do
+  !$omp end target
+  r1 = sum(f%b)
+  r2 = sum(f%d)
+  ok = .true.
+  ok = ok .and. (r1 == 18)
+  ok = ok .and. (r2 == 36)
+  print '(a,i0)', 'r1= ', r1
+  print '(a,i0)', 'r2= ', r2
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', ok)
+end program oop
+! site:
+! title: the second of two member sections of a structure is not copied back
+! summary: map(tofrom: f%b(3:6), f%d(3:6)) on one target construct: the device's writes to f%d do not come back with CCE 19, 20
+! + and 21 when memory is separate (f%b does). One member section works; unified memory works; AFAR and GCC are correct.
+! control: oop/controls/section-fixed.f90 one member section instead of two
+! end site

offload/_root/data/findings/oop/cce-element-component-map-lost.f90

@@ -0,0 +1,64 @@
+! # Finding (fortran-oop): map(tofrom: vk(4)%g(3)) of a component of an array element does not reach the host (copy mode)
+!
+! - toolchains and modes that fail: cce19 (CCE 19.0.0: copy), cce20 (CCE 20.0.2: copy); -O2
+! - build: ftn -fopenmp -O2 (module load cce/<v> craype-accel-amd-gfx942 rocm/<r>; OpenACC: ftn -h acc)
+! - failure: wrong_answer (check=fail); OMP_TARGET_OFFLOAD=mandatory
+! - observed: `r1= 0 r2= 0` at HSA_XNACK=0: the device's write to vk(4)%g(3) is lost on CCE 19 and 20; the same for a section
+!   vk(5)%g(3:5) and a nested element vk(4)%h%c(8); HSA_XNACK=1 correct. CCE 21.0.3 and 21.0.4 lose it in both modes
+!   (cce21-element-component-map-lost.f90, same_as)
+! - expected: `r1= 74 r2= 74`
+! - rule: 5.2 §5.8.3 p.151 l.13 (structure elements and array sections, of an array element, are list items); §5.8.3 p.154 exit
+!   step 1a
+! - same-compiler control: the whole element map(tofrom: vk(5)) (controls/elemsec-element.f90): correct on every CCE in both modes
+!   (results/oop/main/rows.part*.jsonl)
+! - other families: AFAR and GCC 16.2 correct; the AOMP lead dtype-syntax-support (the same map forms) fails on CCE
+! - gate and confirmer: 6 cells, 6 confirmed in the gate's four environments (a-d; results/oop/main/gate_reruns*.jsonl); confirmer
+!   (results/oop/main/confirm.jsonl): needs_human (R22-expected-weak) 6; R22-expected-weak means the expected value has one
+!   source, the generator's Python model; the values follow from the program's arithmetic (checked by hand), and AFAR, GCC 16.2
+!   (gfx90a), GCC 16.2 (sm_80), NVHPC 25.11, NVHPC 26.9 print them on this program
+! - programs (3): oop-elemsec-comp-element, oop-elemsec-comp-section, oop-elemsec-nested-element (offload/engine/oop_gen.py;
+!   this file
+!   is the first one)
+! - legality: for the cce cells: the rules (offload.engine.rules, with the fortran-oop restrictions) and AFAR's flang front end
+!   (-fsyntax-only) and NVHPC 26.9 nvfortran (compile only) (tools/campaigns/oop.py legality, results/oop/main/legality.json)
+module oop_m
+  implicit none
+  integer, parameter :: n = 64
+  type dc
+    integer :: g(20) = 0
+    integer :: i = 0
+  end type dc
+end module oop_m
+
+program oop
+  use omp_lib
+  use oop_m
+  implicit none
+  integer :: host_flag
+  logical :: ok
+  integer :: r1, r2
+  type(dc) :: vk(5)
+  integer :: l
+  host_flag = 1
+  !$omp target map(from: host_flag)
+  host_flag = merge(1, 0, omp_is_initial_device())
+  !$omp end target
+  !$omp target map(tofrom: vk(4)%g(3))
+  vk(4)%g(3) = 74
+  !$omp end target
+  r1 = vk(4)%g(3)
+  r2 = sum(vk(4)%g)
+  ok = .true.
+  ok = ok .and. (r1 == 74)
+  ok = ok .and. (r2 == 74)
+  print '(a,i0)', 'r1= ', r1
+  print '(a,i0)', 'r2= ', r2
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', ok)
+end program oop
+! site:
+! title: a component of an array element mapped tofrom does not come back with separate memory
+! summary: map(tofrom: vk(4)%g(3)), an element of a component of an element of an array of structures: the target region's write
+! + is lost on CCE 19 and 20 when host and device memory are separate. Mapping the whole element vk(5) works. AFAR and GCC are
+! + correct.
+! control: oop/controls/elemsec-element.f90 the whole array element instead of a component of it
+! end site

offload/_root/data/findings/oop/cce-final-dealloc-device-abort.f90

@@ -0,0 +1,85 @@
+! # Finding (fortran-oop): DEALLOCATE of an allocatable finalizable object in device code aborts
+!
+! - toolchains and modes that fail: cce19 (CCE 19.0.0: copy, unified), cce20 (CCE 20.0.2: copy, unified), cce21 (CCE 21.0.3: copy,
+!   unified), cce21_4 (CCE 21.0.4: copy, unified); -O2
+! - build: ftn -fopenmp -O2 (module load cce/<v> craype-accel-amd-gfx942 rocm/<r>; OpenACC: ftn -h acc)
+! - failure: crash / run_error; OMP_TARGET_OFFLOAD=mandatory
+! - observed: CCE 19 and 20: `Thread execution stopped at ... LINE 29 due to a Fortran allocate/deallocate statement` (SIGABRT);
+!   CCE 21.0.3 and 21.0.4: a queue error dump, exit 1; both modes
+! - expected: `r1= 64 r2= 2144`
+! - rule: Fortran 2018 7.5.6.3 para 2 (DEALLOCATE finalizes the object); the final subroutine is declare target (5.2 §1.2.6 p.19)
+! - same-compiler control: a non-allocatable local of the same type (controls/final-local.f90, the family program
+!   oop-assignfinal-final-local): correct on every CCE release and AFAR in both modes, stored run and gate environments a-d
+!   (results/oop/probe/ctl2.*.final-local.*.jsonl)
+! - other families: AFAR fails at the device link (afar-final-dealloc-device-link.f90); GCC 16.2 correct
+! - gate and confirmer: 8 cells, 8 confirmed in the gate's four environments (a-d; results/oop/main/gate_reruns*.jsonl); confirmer
+!   (results/oop/main/confirm.jsonl): needs_human (R22-expected-weak) 8; R22-expected-weak means the expected value has one
+!   source, the generator's Python model; the values follow from the program's arithmetic (checked by hand), and GCC 16.2
+!   (gfx90a), GCC 16.2 (sm_80) print them on this program
+! - programs (1): oop-assignfinal-final-dealloc (offload/engine/oop_gen.py; this file is the first one)
+! - legality: for the cce cells: the rules (offload.engine.rules, with the fortran-oop restrictions) and AFAR's flang front end
+!   (-fsyntax-only) (tools/campaigns/oop.py legality, results/oop/main/legality.json)
+module oop_m
+  implicit none
+  integer, parameter :: n = 64
+  type ft
+    integer :: v = 0
+  contains
+    final :: ft_fin
+  end type ft
+  integer :: fin_count = 0
+  !$omp declare target to(fin_count)
+contains
+  subroutine ft_fin(o)
+    !$omp declare target
+    type(ft), intent(inout) :: o
+    !$omp atomic update
+    fin_count = fin_count + 1
+  end subroutine ft_fin
+  subroutine alloc_work(k, r)
+    !$omp declare target
+    integer, intent(in) :: k
+    integer, intent(out) :: r
+    type(ft), allocatable :: o
+    allocate(o)
+    o%v = k
+    r = o%v + 1
+    deallocate(o)
+  end subroutine alloc_work
+end module oop_m
+
+program oop
+  use omp_lib
+  use oop_m
+  implicit none
+  integer :: host_flag
+  logical :: ok
+  integer :: r1, r2
+  integer :: res(n), i
+  host_flag = 1
+  !$omp target map(from: host_flag)
+  host_flag = merge(1, 0, omp_is_initial_device())
+  !$omp end target
+  fin_count = 0
+  !$omp target update to(fin_count)
+  !$omp target teams distribute parallel do map(tofrom: res)
+  do i = 1, n
+    call alloc_work(i, res(i))
+  end do
+  !$omp target update from(fin_count)
+  r1 = fin_count
+  r2 = sum(res)
+  ok = .true.
+  ok = ok .and. (r1 == 64)
+  ok = ok .and. (r2 == 2144)
+  print '(a,i0)', 'r1= ', r1
+  print '(a,i0)', 'r2= ', r2
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', ok)
+end program oop
+! site:
+! title: deallocating a finalizable object in device code aborts
+! summary: A declare target subroutine allocates and deallocates a local allocatable object of a type with a final subroutine. CCE
+! + 19 and 20 stop the device thread at the DEALLOCATE; CCE 21 aborts with a queue error. The same type as a non-allocatable local
+! + is finalized correctly. GCC runs it correctly.
+! control: oop/controls/final-local.f90 a non-allocatable local of the same finalizable type (no DEALLOCATE)
+! end site

offload/_root/data/findings/oop/cce-pdt-default-mapper-rejected.f90

@@ -0,0 +1,71 @@
+! # Finding (fortran-oop): a derived type with a length type parameter in a map clause is rejected (ftn-1853 in the default mapper)
+!
+! - toolchains and modes that fail: cce19 (CCE 19.0.0: copy, unified), cce20 (CCE 20.0.2: copy, unified), cce21 (CCE 21.0.3: copy,
+!   unified), cce21_4 (CCE 21.0.4: copy, unified); -O2
+! - build: ftn -fopenmp -O2 (module load cce/<v> craype-accel-amd-gfx942 rocm/<r>; OpenACC: ftn -h acc)
+! - failure: rejected (diagnostic); OMP_TARGET_OFFLOAD=mandatory
+! - observed: `ftn-1853 ftn: ERROR default$mapper$lv$oop_m_ ... Missing type parameter value for type` at the type definition,
+!   every CCE release: the compiler-generated default mapper of the type lacks the length parameter
+! - expected: compiles; `r1= 16 r2= 1496`
+! - rule: 5.2 §5.8.3 p.155 l.5-7 (the new list item has the type parameters of the original); a parameterized derived type is
+!   mappable (5.2 §1.2.6 p.18-19)
+! - same-compiler control: the same program with the type's length parameter replaced by a fixed size
+!   (controls/pdt-len-unparameterized.f90, one change): correct (check=pass) on CCE 19, 20, 21.0.3 and 21.0.4 in both modes in the
+!   stored run and the gate's four environments a-d, (c) on another node or GPU
+!   (results/oop/probe/ctl2.*.pdt-len-unparameterized.*.jsonl); a kind type parameter alone (controls/pdt-kind.f90) is correct too
+!   (results/oop/main/rows.part*.jsonl)
+! - other families: AFAR: 'not yet implemented' for length parameters (afar-pdt-length-parameter-not-implemented.f90); GCC 16.2
+!   compiles them and aborts (gcc-pdt-length-parameter-abort.f90)
+! - gate and confirmer: 32 cells, 32 confirmed in the gate's four environments (a-d; results/oop/main/gate_reruns*.jsonl);
+!   confirmer (results/oop/main/confirm.jsonl): compiler_bug (R11-compile-rejection) 16, unsupported_everywhere
+!   (R12-every-family-rejects) 16
+! - programs (4): oop-pdt-len, oop-pdt-deferred, oop-pdt-array, oop-pdt-kindlen (offload/engine/oop_gen.py; this file is the first
+!   one)
+! - legality: for the cce cells: the rules (offload.engine.rules, with the fortran-oop restrictions) and AFAR's flang front end
+!   (-fsyntax-only) and NVHPC 26.9 nvfortran (compile only) (tools/campaigns/oop.py legality, results/oop/main/legality.json)
+module oop_m
+  implicit none
+  integer, parameter :: n = 64
+  type lv(m)
+  integer, len :: m
+  integer :: a(m)
+  end type lv
+end module oop_m
+
+program oop
+  use omp_lib
+  use oop_m
+  implicit none
+  integer :: host_flag
+  logical :: ok
+  integer :: r1, r2
+  type(lv(16)) :: x
+  integer :: i
+  host_flag = 1
+  !$omp target map(from: host_flag)
+  host_flag = merge(1, 0, omp_is_initial_device())
+  !$omp end target
+  do i = 1, 16
+    x%a(i) = i
+  end do
+  !$omp target map(tofrom: x) map(from: r1)
+  r1 = x%m
+  do i = 1, x%m
+    x%a(i) = x%a(i) * x%a(i)
+  end do
+  !$omp end target
+  r2 = sum(x%a)
+  ok = .true.
+  ok = ok .and. (r1 == 16)
+  ok = ok .and. (r2 == 1496)
+  print '(a,i0)', 'r1= ', r1
+  print '(a,i0)', 'r2= ', r2
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', ok)
+end program oop
+! site:
+! title: a derived type with a length type parameter cannot be mapped
+! summary: Mapping a variable of a parameterized derived type with a length type parameter (type(lv(16)) :: x; map(tofrom: x)) is
+! + rejected by CCE 19, 20 and 21 with ftn-1853 'Missing type parameter value' in the compiler's generated default mapper. The same
+! + program with a fixed size in place of the length parameter works.
+! control: oop/controls/pdt-len-unparameterized.f90 the same program; the type has no length parameter (a fixed size instead)
+! end site

offload/_root/data/findings/oop/cce-polymorphic-dispatch-device-link.f90

@@ -0,0 +1,100 @@
+! # Finding (fortran-oop): a type-bound call through a CLASS dummy in device code fails to link (__GET_TYPE_BOUND_PROC)
+!
+! - toolchains and modes that fail: cce19 (CCE 19.0.0: copy, unified), cce20 (CCE 20.0.2: copy, unified), cce21 (CCE 21.0.3: copy,
+!   unified), cce21_4 (CCE 21.0.4: copy, unified); -O2
+! - build: ftn -fopenmp -O2 (module load cce/<v> craype-accel-amd-gfx942 rocm/<r>; OpenACC: ftn -h acc)
+! - failure: rejected (link_undefined_symbol, the program's own object); OMP_TARGET_OFFLOAD=mandatory
+! - observed: `lld: error: undefined symbol: __GET_TYPE_BOUND_PROC` at the device link, every CCE release, both modes: dynamic
+!   dispatch of a binding of an abstract type, in a loop, through an override that calls its parent's binding, through a
+!   polymorphic pointer, and a binding that calls another binding of its CLASS dummy
+! - expected: compiles; `r1= 29` (area of a 3x3 square plus a 4x5 rectangle)
+! - rule: every type-bound procedure the region accesses is in a declare target directive (5.2 §1.2.6 p.19 l.1-3; checked by the
+!   rules, typebound-declaretarget-001), which is all OpenMP asks of a derived type used in a target region
+! - same-compiler control: the same program with the region calling the binding on the TYPE objects, q%area() + rr%area(), instead
+!   of area_of's CLASS(shape) dummy (controls/poly-dispatch-static.f90, one change): correct (check=pass) on CCE 19, 20, 21.0.3
+!   and 21.0.4 in both modes, in the stored run and the gate's four environments a-d with (c) on another node
+!   (results/oop/probe/ctl2.*.poly-dispatch-static.*.jsonl)
+! - other families: AFAR correct on all five; GCC 16.2 compiles them and aborts at run time (gcc-polymorphic-dispatch-abort.f90);
+!   OpenACC's routine form (unspecified behaviour) fails the same way on CCE with ftn-7066 'Unsupported accelerator code error:
+!   Calls -- __GET_TYPE_BOUND_PROC'
+! - gate and confirmer: 40 cells, 40 confirmed in the gate's four environments (a-d; results/oop/main/gate_reruns*.jsonl);
+!   confirmer (results/oop/main/confirm.jsonl): compiler_bug (R10b-own-link-or-hang) 40
+! - programs (5): oop-poly-dispatch, oop-poly-dispatch-loop, oop-poly-parent-call, oop-poly-pointer, oop-tbp-nested-call
+!   (offload/engine/oop_gen.py; this file is the first one)
+! - legality: for the cce cells: the rules (offload.engine.rules, with the fortran-oop restrictions) and AFAR's flang front end
+!   (-fsyntax-only) and NVHPC 26.9 nvfortran (compile only) (tools/campaigns/oop.py legality, results/oop/main/legality.json)
+module oop_m
+  implicit none
+  integer, parameter :: n = 64
+  type, abstract :: shape
+    integer :: id = 0
+  contains
+    procedure(area_if), deferred :: area
+  end type shape
+  abstract interface
+    integer function area_if(s)
+      import :: shape
+      class(shape), intent(in) :: s
+    end function area_if
+  end interface
+  type, extends(shape) :: sq
+    integer :: side = 0
+  contains
+    procedure :: area => sq_area
+  end type sq
+  type, extends(shape) :: rect
+    integer :: w = 0, h = 0
+  contains
+    procedure :: area => rect_area
+  end type rect
+contains
+  integer function sq_area(s)
+    !$omp declare target
+    class(sq), intent(in) :: s
+    sq_area = s%side * s%side
+  end function sq_area
+  integer function rect_area(s)
+    !$omp declare target
+    class(rect), intent(in) :: s
+    rect_area = s%w * s%h
+  end function rect_area
+  integer function area_of(s)
+    !$omp declare target
+    class(shape), intent(in) :: s
+    area_of = s%area()
+  end function area_of
+end module oop_m
+
+program oop
+  use omp_lib
+  use oop_m
+  implicit none
+  integer :: host_flag
+  logical :: ok
+  integer :: r1
+  type(sq) :: q
+  type(rect) :: rr
+  host_flag = 1
+  !$omp target map(from: host_flag)
+  host_flag = merge(1, 0, omp_is_initial_device())
+  !$omp end target
+  q%side = 3
+  rr%w = 4
+  rr%h = 5
+  !$omp target map(tofrom: q, rr) map(from: r1)
+  r1 = area_of(q) + area_of(rr)
+  !$omp end target
+  ok = .true.
+  ok = ok .and. (r1 == 29)
+  print '(a,i0)', 'r1= ', r1
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', ok)
+end program oop
+! site:
+! title: dynamic dispatch of a type-bound procedure in device code fails at the link
+! summary: A declare target function calls a type-bound procedure through a CLASS(shape) dummy argument (dynamic dispatch); every
+! + procedure bound to the binding is declare target. CCE 19, 20 and 21 fail at the device link with an undefined
+! + __GET_TYPE_BOUND_PROC. The same program calling the binding on the non-polymorphic objects themselves (no dispatch) works. AFAR
+! + compiles and runs the program correctly.
+! control: oop/controls/poly-dispatch-static.f90 the same program; the binding is called on the TYPE objects (statically resolved)
+! + instead of through a CLASS dummy
+! end site

offload/_root/data/findings/oop/cce-section-of-element-component-overlap.f90

@@ -0,0 +1,76 @@
+! # Finding (fortran-oop): mapping the allocatable component of an array element aborts: 'overlaps present region'
+!
+! - toolchains and modes that fail: cce19 (CCE 19.0.0: copy, unified), cce20 (CCE 20.0.2: copy, unified), cce21 (CCE 21.0.3: copy,
+!   unified), cce21_4 (CCE 21.0.4: copy, unified); -O2
+! - build: ftn -fopenmp -O2 (module load cce/<v> craype-accel-amd-gfx942 rocm/<r>; OpenACC: ftn -h acc)
+! - failure: run_error (exit 1); OMP_TARGET_OFFLOAD=mandatory
+! - observed: `CRAY_ACC_ERROR - Host region ... overlaps present region ... but is not contained for 't$2(:)'` at the target
+!   construct, every CCE release, both modes. Mapping the whole component v(2)%a instead of its section
+!   (controls/section-element-whole-component.f90) stops with the same message in every environment a-d
+!   (results/oop/probe/ctl2.*.section-element-whole-component.*.jsonl): the defect is the component of an array element, not
+!   the section
+! - expected: `r1= 2880 r2= 2080`
+! - rule: 5.2 §5.8.3 p.151 l.13; the construct maps one list item, so no earlier storage overlaps it (§5.8.3 p.156 l.19-22 is
+!   about storage present before the construct)
+! - same-compiler control: the same program mapping the whole array v (controls/section-element-whole-array.f90, one change:
+!   map(tofrom: v), whose default mapper maps each element's component): correct (check=pass) on CCE 19, 20, 21.0.3 and 21.0.4 in
+!   both modes, in the stored run and the gate's four environments a-d with (c) on another node
+!   (results/oop/probe/ctl2.*.section-element-whole-array.*.jsonl)
+! - other families: AFAR and GCC 16.2 correct; related to harvest/cce-c-implicit-struct-map-partly-present.c (the same runtime
+!   message for a structure whose members are present)
+! - gate and confirmer: 8 cells, 8 confirmed in the gate's four environments (a-d; results/oop/main/gate_reruns*.jsonl); confirmer
+!   (results/oop/main/confirm.jsonl): needs_human (R22-expected-weak) 8; R22-expected-weak means the expected value has one
+!   source, the generator's Python model; the values follow from the program's arithmetic (checked by hand), and AFAR, GCC 16.2
+!   (gfx90a), GCC 16.2 (sm_80), NVHPC 25.11, NVHPC 26.9 print them on this program
+! - programs (1): oop-section-element (offload/engine/oop_gen.py; this file is the first one)
+! - legality: for the cce cells: the rules (offload.engine.rules, with the fortran-oop restrictions) and AFAR's flang front end
+!   (-fsyntax-only) and NVHPC 26.9 nvfortran (compile only) (tools/campaigns/oop.py legality, results/oop/main/legality.json)
+module oop_m
+  implicit none
+  integer, parameter :: n = 64
+  type vec
+    integer :: n = 0
+    integer, allocatable :: a(:)
+  end type vec
+end module oop_m
+
+program oop
+  use omp_lib
+  use oop_m
+  implicit none
+  integer :: host_flag
+  logical :: ok
+  integer :: r1, r2
+  type(vec) :: v(3)
+  integer :: i, k
+  host_flag = 1
+  !$omp target map(from: host_flag)
+  host_flag = merge(1, 0, omp_is_initial_device())
+  !$omp end target
+  do k = 1, 3
+    allocate(v(k)%a(n))
+    v(k)%n = n
+    do i = 1, n
+      v(k)%a(i) = i
+    end do
+  end do
+  !$omp target teams distribute parallel do map(tofrom: v(2)%a(5:20))
+  do i = 5, 20
+    v(2)%a(i) = v(2)%a(i) + 50
+  end do
+  r1 = sum(v(2)%a)
+  r2 = sum(v(1)%a)
+  ok = .true.
+  ok = ok .and. (r1 == 2880)
+  ok = ok .and. (r2 == 2080)
+  print '(a,i0)', 'r1= ', r1
+  print '(a,i0)', 'r2= ', r2
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', ok)
+end program oop
+! site:
+! title: mapping the allocatable component of an array element aborts as a partial overlap
+! summary: map(tofrom: v(2)%a(5:20)) (v an array of structures with an allocatable component; the whole component v(2)%a too)
+! + aborts at the target construct on CCE 19, 20 and 21 in both memory modes: the runtime reports that the host region overlaps a
+! + present region but is not contained in it. Mapping the whole array v works. AFAR and GCC run it correctly.
+! control: oop/controls/section-element-whole-array.f90 the same program mapping the whole array v
+! end site