offtarget 0.1.0__py3-none-any.whl

offload/_root/data/findings/oop/gcc-acc-parent-and-member-data-rejected.f90

@@ -0,0 +1,63 @@
+! # Finding (fortran-oop): OpenACC data copyin(x) copy(x%a): 'Symbol x has mixed component and non-component accesses'
+!
+! - toolchains and modes that fail: gcc_g90 (GCC 16.2 (gfx90a): copy), gcc_sm80 (GCC 16.2 (sm_80): copy); -O2
+! - build: gfortran -fopenacc -foffload=amdgcn-amdhsa -foffload-options=amdgcn-amdhsa=-march=gfx90a -O2 (gcc_g90); -fopenacc
+!   -foffload=nvptx-none -foffload-options=nvptx-none=-march=sm_80 (gcc_sm80)
+! - failure: rejected (diagnostic)
+! - observed: `Error: Symbol 'x' has mixed component and non-component accesses`
+! - expected: compiles; `r1= 4160`
+! - rule: OpenACC 3.4 §2.7.1 p.50 l.1711-1713 (a derived-type variable's allocatable members' data are not copied with it) and
+!   §2.6.4 p.43 l.1449-1458 (a member in a data clause is attached): the manual deep copy the specification describes
+! - same-compiler control: the same deep copy by enter data copyin(x) then copyin(x%a) (oop-acc-deep-enterexit): correct
+! - other families: CCE 19, 20, 21 correct in both modes
+! - gate and confirmer: 2 cells, 2 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) 2
+! - programs (1): oop-acc-deep-data (offload/engine/oop_gen.py; this file is the first one)
+! - legality: for the gcc cells: the rules (offload.engine.rules, with the fortran-oop restrictions) and AFAR's flang front end
+!   (-fsyntax-only) and a CCE compile 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 openacc
+  use oop_m
+  implicit none
+  integer :: host_flag
+  logical :: ok
+  integer :: r1
+  type(vec) :: x
+  integer :: i
+  host_flag = 1
+  !$acc serial copy(host_flag)
+  host_flag = merge(1, 0, acc_on_device(acc_device_host))
+  !$acc end serial
+  allocate(x%a(n))
+  x%n = n
+  do i = 1, n
+    x%a(i) = i
+  end do
+  !$acc data copyin(x) copy(x%a)
+  !$acc parallel loop
+  do i = 1, n
+    x%a(i) = 2 * x%a(i)
+  end do
+  !$acc end data
+  r1 = sum(x%a)
+  ok = .true.
+  ok = ok .and. (r1 == 4160)
+  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: OpenACC: a structure and its member in one data construct are rejected
+! summary: An OpenACC data construct with copyin(x) copy(x%a), the specification's manual deep copy of an allocatable member, is
+! + rejected by GCC 16.2 ('mixed component and non-component accesses'). The same deep copy with two enter data directives works.
+! + CCE is correct.
+! end site

offload/_root/data/findings/oop/gcc-pdt-length-parameter-abort.f90

@@ -0,0 +1,68 @@
+! # Finding (fortran-oop): mapping a derived type with a length type parameter aborts at run time
+!
+! - toolchains and modes that fail: gcc_g90 (GCC 16.2 (gfx90a): copy), gcc_sm80 (GCC 16.2 (sm_80): copy); -O2
+! - build: gfortran -fopenmp -foffload=amdgcn-amdhsa -foffload-options=amdgcn-amdhsa=-march=gfx90a -O2 (gcc_g90);
+!   -foffload=nvptx-none -foffload-options=nvptx-none=-march=sm_80 -foffload-options=nvptx-none=-latomic (gcc_sm80)
+! - failure: crash (SIGABRT); OMP_TARGET_OFFLOAD=mandatory
+! - observed: compiles; aborts (SIGABRT) in every run; the deferred-length allocatable form (oop-pdt-deferred) aborts in some runs
+!   only (nondeterministic in the gate, not counted)
+! - expected: `r1= 16 r2= 1496`
+! - rule: 5.2 §5.8.3 p.155 l.5-7
+! - same-compiler control: the same program without the target construct (controls/pdt-len-host.f90, one change: the PDT work runs
+!   on the host): `r1= 16 r2= 1496`, check=pass in the stored run and the gate's four environments on both machines
+!   (results/oop/probe/ctl2.*.pdt-len-host.gcc.jsonl, results/oop/probe/ctl2.*.pdt-len-host.wt-gcc_sm80.jsonl), so the abort is
+!   the offload's; a
+!   kind type parameter only (controls/pdt-kind.f90) is correct too (results/oop/main/rows.part*.jsonl)
+! - other families: AFAR (not implemented) and CCE (ftn-1853) reject the programs
+! - 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 NVHPC 25.11,
+!   NVHPC 26.9 print them on this program
+! - programs (3): oop-pdt-len, oop-pdt-array, oop-pdt-kindlen (offload/engine/oop_gen.py; this file is the first one)
+! - legality: for the gcc 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: mapping a derived type with a length type parameter aborts
+! summary: A variable of a parameterized derived type with a length type parameter, mapped tofrom, makes the program abort at run
+! + time with GCC 16.2. A kind type parameter works.
+! control: oop/controls/pdt-len-host.f90 the same program without the target construct (host only)
+! end site

offload/_root/data/findings/oop/gcc-polymorphic-dispatch-abort.f90

@@ -0,0 +1,97 @@
+! # Finding (fortran-oop): a type-bound call through a CLASS dummy in device code aborts at run time
+!
+! - toolchains and modes that fail: gcc_g90 (GCC 16.2 (gfx90a): copy), gcc_sm80 (GCC 16.2 (sm_80): copy); -O2
+! - build: gfortran -fopenmp -foffload=amdgcn-amdhsa -foffload-options=amdgcn-amdhsa=-march=gfx90a -O2 (gcc_g90);
+!   -foffload=nvptx-none -foffload-options=nvptx-none=-march=sm_80 -foffload-options=nvptx-none=-latomic (gcc_sm80)
+! - failure: crash (SIGABRT); OMP_TARGET_OFFLOAD=mandatory
+! - observed: the program compiles and aborts (SIGABRT, a backtrace without symbols) in every run
+! - expected: `r1= 29`
+! - rule: 5.2 §1.2.6 p.19 l.1-3 (every type-bound procedure accessed is declare target)
+! - same-compiler control: the same program with the region calling the binding on the TYPE objects instead of through area_of's
+!   CLASS(shape) dummy (controls/poly-dispatch-static.f90, one change): `r1= 29`, check=pass in the stored run and the gate's four
+!   environments a-d on both GPUs (results/oop/probe/ctl2.*.poly-dispatch-static.gcc.jsonl, (c) on another Tioga node;
+!   results/oop/probe/ctl2.*.poly-dispatch-static.wt-gcc_sm80.jsonl, (c) on another A100)
+! - other families: AFAR correct; CCE fails at the device link (cce-polymorphic-dispatch-device-link.f90)
+! - 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): compiler_bug (R20-runtime-bug) 4, 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 print them on this program
+! - programs (4): oop-poly-dispatch, oop-poly-dispatch-loop, oop-poly-parent-call, oop-tbp-nested-call (offload/engine/oop_gen.py;
+!   this file is the first one)
+! - legality: for the gcc cells: the rules (offload.engine.rules, with the fortran-oop restrictions) and AFAR's flang front end
+!   (-fsyntax-only) and a CCE compile 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 aborts
+! summary: A declare target function calls a type-bound procedure through a CLASS dummy argument (every bound procedure declare
+! + target). GCC 16.2 compiles it and the program aborts at run time. The same program calling the binding on the non-polymorphic
+! + objects works. AFAR runs it 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/gcc-vtab-not-marked-for-offload.f90

@@ -0,0 +1,94 @@
+! # Finding (fortran-oop): SELECT TYPE on a CLASS dummy in device code: '__vtab_... referenced in offloaded code but not marked'
+!
+! - toolchains and modes that fail: gcc_g90 (GCC 16.2 (gfx90a): copy), gcc_sm80 (GCC 16.2 (sm_80): copy); -O2
+! - build: gfortran -fopenmp -foffload=amdgcn-amdhsa -foffload-options=amdgcn-amdhsa=-march=gfx90a -O2 (gcc_g90);
+!   -foffload=nvptx-none -foffload-options=nvptx-none=-march=sm_80 -foffload-options=nvptx-none=-latomic (gcc_sm80)
+! - failure: rejected (diagnostic); OMP_TARGET_OFFLOAD=mandatory
+! - observed: `error: variable '__vtab_oop_m_Ext1' has been referenced in offloaded code but hasn't been marked to be included in
+!   the offloaded code` (the compiler's own type descriptor)
+! - expected: compiles; `r1= 10 r2= 100 r3= -1`
+! - rule: Fortran 2018 11.1.11; the program cannot name a compiler-generated vtable in a declare target directive (it has no
+!   Fortran name), and every procedure it accesses is declare target
+! - other families: AFAR correct; CCE takes the wrong guard (cce-select-type-guard-not-taken.f90)
+! - gate and confirmer: 10 cells, 10 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) 5, needs_human (R12b-compile-undecided) 5
+! - programs (5): oop-poly-select-type, oop-poly-class-is, oop-poly-pointer, oop-unlimited-select-type, oop-unlimited-classify
+!   (offload/engine/oop_gen.py; this file is the first one)
+! - legality: for the gcc cells: the rules (offload.engine.rules, with the fortran-oop restrictions) and AFAR's flang front end
+!   (-fsyntax-only) and a CCE compile 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 base_t
+    integer :: a = 0
+  end type base_t
+  type, extends(base_t) :: ext1
+    integer :: u = 0
+  end type ext1
+  type, extends(base_t) :: ext2
+    integer :: v = 0
+  end type ext2
+contains
+  subroutine bump(s)
+    !$omp declare target
+    class(base_t), intent(inout) :: s
+    select type (s)
+      type is (ext1)
+        s%u = s%u + 10
+      type is (ext2)
+        s%v = s%v + 100
+      class default
+        s%a = -1
+    end select
+  end subroutine bump
+end module oop_m
+
+program oop
+  use omp_lib
+  use oop_m
+  implicit none
+  integer :: host_flag
+  logical :: ok
+  integer :: r1, r2, r3
+  type(ext1) :: e1
+  type(ext2) :: e2
+  type(base_t) :: b0
+  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: e1, e2, b0)
+  call bump(e1)
+  call bump(e2)
+  call bump(b0)
+  !$omp end target
+  r1 = e1%u
+  r2 = e2%v
+  r3 = b0%a
+  ok = .true.
+  ok = ok .and. (r1 == 10)
+  ok = ok .and. (r2 == 100)
+  ok = ok .and. (r3 == -1)
+  print '(a,i0)', 'r1= ', r1
+  print '(a,i0)', 'r2= ', r2
+  print '(a,i0)', 'r3= ', r3
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', ok)
+end program oop
+! site:
+! title: SELECT TYPE in a device procedure is rejected: the type's vtable is not offloaded
+! summary: A declare target subroutine with a CLASS dummy and SELECT TYPE, called in a target region, is rejected by GCC 16.2: the
+! + compiler-generated type descriptor (__vtab_...) is referenced in offloaded code but not marked for offloading. The program
+! + cannot name that variable. AFAR runs the program correctly.
+! end site
+! spec (requirement): the base language is Fortran 2003, 2008 and 2018 with only a short list of features of unspecified
+!   behavior (SELECT TYPE is not on it; its semantics are the Fortran standard's, with no OpenMP text of its own), and a variable
+!   with static storage duration declared in a device routine is treated as if it appeared in an enter clause of a declare target
+!   directive. No text covers compiler-generated type descriptors; the nearest rule is this implicit declare target rule.
+! "While future versions of the OpenMP specification are expected to address the following features, currently their use may
+!   result in unspecified behavior." (5.2 §1.7 p.36 l.6-8)
+! "If a variable with static storage duration is declared in a device routine then the named variable is treated as if it had
+!   appeared in an enter clause on a declare target directive." (5.2 §7.8 p.204 l.25-26)
+! spec (this program): bump is a declare target subroutine with a CLASS dummy and SELECT TYPE; the compiler's own type
+!   descriptor (__vtab_...), which has no Fortran name and cannot appear in a declare target directive, is a static variable the
+!   device routine needs, and GCC 16.2 rejects the program because that variable is not marked for offloading.

offload/_root/data/findings/oop/nvhpc-copy-alloc-component-illegal-address.f90

@@ -0,0 +1,76 @@
+! # Finding (fortran-oop): map(tofrom: x) of a structure with an allocatable component: illegal address with separate memory
+!
+! - toolchains and modes that fail: nvhpc (NVHPC 25.11: separate), nvhpc269 (NVHPC 26.9: separate); -O2
+! - build: nvfortran -mp=gpu -gpu=cc80 -O2 (managed: -gpu=mem:managed)
+! - failure: run_error (exit 1); OMP_TARGET_OFFLOAD=mandatory
+! - observed: `Accelerator Fatal Error: call to cuMemcpyDtoHAsync returned error 700 (CUDA_ERROR_ILLEGAL_ADDRESS)` in separate
+!   memory on NVHPC 25.11 and 26.9, whenever the allocatable component is mapped only through the structure (map(tofrom: x),
+!   target enter data map(to: x), an array of such structures, an allocatable scalar component, two levels, an extended type's
+!   allocatable parent component); managed memory correct
+! - expected: `r1= 10336 r2= 256`
+! - rule: the predefined default mapper maps each structure element, an allocatable component's data included (5.2 §5.8.2 p.150
+!   l.2-4; §5.8.3 p.151 l.29-37; added in 5.0, 6.0 §B.5 p.909 l.35-37)
+! - same-compiler control: the same program with the component listed, map(tofrom: x, x%a)
+!   (controls/alloccomp-whole-explicit-component.f90, one change): correct (check=pass) on NVHPC 25.11 and 26.9, separate and
+!   managed memory, in the stored run and the gate's four environments a-d, (c) on another GPU of the host
+!   (results/oop/probe/ctl2.*.alloccomp-whole-explicit-component.wt-*.jsonl)
+! - other families: AFAR, CCE 19/20/21 and GCC 16.2 correct on all nine
+! - gate and confirmer: 18 cells, 18 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) 18; 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, CCE
+!   19.0.0, CCE 20.0.2, CCE 21.0.3, CCE 21.0.4, GCC 16.2 (gfx90a), GCC 16.2 (sm_80) print them on this program
+! - programs (9): oop-alloccomp-whole, oop-alloccomp-array, oop-alloccomp-enterexit, oop-alloccomp-scalar, oop-alloccomp-twolevel,
+!   oop-alloccomp-update, oop-extends-alloc-parent, oop-elemsec-alloc-chain, oop-section-update (offload/engine/oop_gen.py;
+!   this file
+!   is the first one)
+! - legality: for the nvhpc cells: the rules (offload.engine.rules, with the fortran-oop restrictions) and AFAR's flang front end
+!   (-fsyntax-only) and a CCE compile (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)
+  do i = 1, n
+    x%a(i) = 3 * x%a(i) + x%n
+  end do
+  r1 = sum(x%a)
+  r2 = x%a(n)
+  ok = .true.
+  ok = ok .and. (r1 == 10336)
+  ok = ok .and. (r2 == 256)
+  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 allocatable component of a mapped structure is not mapped with separate memory
+! summary: A structure with an allocatable array component mapped by map(tofrom: x) should carry the component's data to the
+! + device (the predefined default mapper maps each component). NVHPC 25.11 and 26.9 fault with an illegal address when memory is
+! + separate; with the component listed, map(tofrom: x, x%a), the program works, and managed memory works. AFAR, CCE and GCC are
+! + correct.
+! control: oop/controls/alloccomp-whole-explicit-component.f90 the same program with the component listed in the map clause
+! end site

offload/_root/data/findings/oop/nvhpc-copy-pdt-length-parameter-illegal-address.f90

@@ -0,0 +1,69 @@
+! # Finding (fortran-oop): mapping a derived type with a length type parameter: illegal address with separate memory
+!
+! - toolchains and modes that fail: nvhpc (NVHPC 25.11: separate), nvhpc269 (NVHPC 26.9: separate); -O2
+! - build: nvfortran -mp=gpu -gpu=cc80 -O2 (managed: -gpu=mem:managed)
+! - failure: run_error (exit 1); OMP_TARGET_OFFLOAD=mandatory
+! - observed: `cuMemcpyDtoHAsync returned error 700 (CUDA_ERROR_ILLEGAL_ADDRESS)` in separate memory, NVHPC 25.11 and 26.9;
+!   managed memory correct
+! - expected: `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)
+! - 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 NVHPC 25.11 and 26.9, separate and managed memory
+!   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, results/oop/probe/ctl2.*.pdt-kind.*.jsonl)
+! - other families: AFAR (not implemented) and CCE (ftn-1853) reject the programs; GCC 16.2 aborts
+! - 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 no compiler
+!   outside the failing family prints them on this program
+! - 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 nvhpc 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 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: mapping a derived type with a length type parameter faults with separate memory
+! summary: A variable of a parameterized derived type with a length type parameter, mapped tofrom, faults with an illegal address
+! + on NVHPC 25.11 and 26.9 when memory is separate; managed memory works. The same program with the type's length parameter
+! + replaced by a fixed size 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/nvhpc-named-mapper-rejected.f90

@@ -0,0 +1,65 @@
+! # Finding (fortran-oop): map(mapper(deep), tofrom: x) with a declare mapper: rejected (mapper(mapid) is not supported)
+!
+! - toolchains and modes that fail: nvhpc (NVHPC 25.11: managed, separate), nvhpc269 (NVHPC 26.9: managed, separate); -O2
+! - build: nvfortran -mp=gpu -gpu=cc80 -O2 (managed: -gpu=mem:managed)
+! - failure: rejected (not_implemented); OMP_TARGET_OFFLOAD=mandatory
+! - observed: `NVFORTRAN-W-0287-Unrecognized OpenMP directive - declare` for the declare mapper directive, then the map clause
+!   naming the mapper does not compile, NVHPC 25.11 and 26.9, separate and managed memory. The default-mapper programs
+!   (oop-mapper-default and four others) get the same warning and then run with the predefined default mapper, which in those
+!   programs has the same effect: not counted here (their separate-memory failures are
+!   nvhpc-copy-alloc-component-illegal-address.f90's)
+! - expected: compiles; `r1= 133120`
+! - rule: 5.2 §5.8.8 p.162-164 (declare mapper) and §5.8.2 (the mapper modifier); NVHPC documents the gap: the NVIDIA HPC
+!   Compilers User's Guide §7.4 "OpenMP Subset" (the OpenMP 5.0 features the compilers support) lists for 2.19.7 that
+!   mapper(mapid) is not supported, and does not list declare mapper
+! - other families: AFAR and CCE correct; GCC rejects it (gcc/gcc-declare-mapper-rejected.f90)
+! - 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): unsupported (R05-unsupported) 4
+! - programs (1): oop-mapper-named (offload/engine/oop_gen.py; this file is the first one)
+! - legality: for the nvhpc cells: the rules (offload.engine.rules, with the fortran-oop restrictions) and AFAR's flang front end
+!   (-fsyntax-only) and a CCE compile (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
+  !$omp declare mapper(deep: vec :: v) map(tofrom: v, v%a(1:v%n))
+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(mapper(deep), tofrom: x)
+  do i = 1, n
+    x%a(i) = x%a(i) * x%n
+  end do
+  r1 = sum(x%a)
+  ok = .true.
+  ok = ok .and. (r1 == 133120)
+  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: a named declare mapper (map(mapper(id), ...)) is not supported
+! summary: A map clause with a mapper modifier naming a declare mapper does not compile with NVHPC 25.11 and 26.9; the declare
+! + mapper directive itself is reported as unrecognized. NVHPC's user guide lists mapper(mapid) as not supported. AFAR and CCE apply
+! + the mapper correctly.
+! end site

offload/_root/data/findings/oop/nvhpc-polymorphic-dispatch-translate-failure.f90

@@ -0,0 +1,90 @@
+! # Finding (fortran-oop): dispatch through a CLASS dummy in device code: 'Compiler failed to translate accelerator region'
+!
+! - toolchains and modes that fail: nvhpc (NVHPC 25.11: managed, separate), nvhpc269 (NVHPC 26.9: managed, separate); -O2
+! - build: nvfortran -mp=gpu -gpu=cc80 -O2 (managed: -gpu=mem:managed)
+! - failure: ice (a compiler failure: failed to translate); OMP_TARGET_OFFLOAD=mandatory
+! - observed: `NVFORTRAN-W-0155-Compiler failed to translate accelerator region (see -Minfo messages): No device symbol for
+!   address reference`, then the compile fails, NVHPC 25.11 and 26.9, both modes. A compiler failure: the message does not say the
+!   feature is unsupported and the user guide does not mention it
+! - expected: compiles; `r1= 29`
+! - rule: 5.2 §1.2.6 p.19 l.1-3 (every type-bound procedure accessed is declare target)
+! - other families: AFAR correct; CCE fails at the link (cce-polymorphic-dispatch-device-link.f90); GCC aborts at run time
+!   (gcc-polymorphic-dispatch-abort.f90)
+! - 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): compiler_bug (R10-compile-ice) 12
+! - programs (3): oop-poly-dispatch, oop-poly-dispatch-loop, oop-poly-parent-call (offload/engine/oop_gen.py; this file is the first
+!   one)
+! - legality: for the nvhpc cells: the rules (offload.engine.rules, with the fortran-oop restrictions) and AFAR's flang front end
+!   (-fsyntax-only) and a CCE compile (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 makes the compiler fail
+! summary: A declare target function calls a type-bound procedure through a CLASS dummy argument. NVHPC 25.11 and 26.9 stop with
+! + 'Compiler failed to translate accelerator region'. AFAR runs it correctly.
+! end site