offtarget 0.1.0__py3-none-any.whl

offload/_root/data/findings/nvhpc-c-parallel-if-in-target-nvvm-ice.c

@@ -0,0 +1,56 @@
+// NVHPC 25.11, NVIDIA A100 80GB PCIe (wingtip, sm_80), both memory modes: the C
+// form of nvhpc-parallel-if-in-target-nvvm-ice.f90. An if clause on a parallel
+// for in a target region, whose body calls omp_get_num_threads, makes the
+// device compiler fail (nvvmCompileProgram: failed with error 9:
+// NVVM_ERROR_COMPILATION, "'@nvkernel_main_...' defined with type 'void (i8*,
+// i8*, i8*)*'") instead of compiling the program or giving a diagnostic.
+// Without the omp_get_num_threads call the program compiles.
+// Spec: the if clause is one of the inputs that "are used to determine the
+// number of threads to use in the region" (5.2 §10.1.1 p.226).
+// Vendor: "The if and copyin clauses are supported only for CPU targets; the
+// compiler emits an error for GPU targets" (HPC Compilers User's Guide 25.11
+// §7.4, 2.6): documented unsupported, so the bug is the internal failure where
+// a diagnostic is promised. The guide's §2.20 sentence "nested teams or
+// parallel regions in a target region are not supported" is read as a
+// parallel region nested in another parallel (or teams) region inside a
+// target region; here the parallel region is the only one in the target
+// region.
+// Expected: "sum 2080 nthr 1" (or a diagnostic naming the if clause).
+// Observed (2026-10-24, nvc 25.11-0, -O2): compile exit status 2 with the NVVM
+// error.
+// Found by the catalog (omp52/60-c-clause-if: confirmer R10-compile-ice);
+// reduced by hand.
+// NVHPC 26.9 (26.9-0, the latest release; rerun 2026-10-24 on wingtip with
+// the same flags): still present -- the same NVVM error, both modes.
+// Fix (2026-10-24): rerun on 25.11 and 26.9 in both memory modes,
+// each with its own runtime libraries (LD_LIBRARY_PATH = the release's
+// compilers/lib; the first 26.9 runs had loaded 25.11's): still present
+// on both releases, the same output.
+// NVHPC: nvc -mp=gpu -gpu=cc80 -gpu=mem:separate -O2
+#include <stdio.h>
+#include <stdbool.h>
+#include <omp.h>
+int main(void) {
+  int a[64];
+  int nthr = 0;
+  bool use_par = false;
+  for (int i = 0; i < 64; i++) a[i] = 0;
+  #pragma omp target map(tofrom: a) map(from: nthr)
+  {
+    #pragma omp parallel for if(use_par)
+    for (int i = 0; i < 64; i++) {
+      a[i] = i + 1;
+      if (i == 0) nthr = omp_get_num_threads();
+    }
+  }
+  int s = 0;
+  for (int i = 0; i < 64; i++) s += a[i];
+  printf("sum %d nthr %d\n", s, nthr);
+  return 0;
+}
+// site:
+// title: nvfortran/nvc -mp=gpu: if clause on a parallel loop in a target region gives an internal NVVM error instead of the
+// + documented diagnostic
+// control: ../vendor/checks/src/nvhpc/control/nvhpc-c-parallel-if-in-target-nvvm-ice-control.c the if clause removed
+// same_as: nvhpc-parallel-if-in-target-nvvm-ice
+// end site

offload/_root/data/findings/nvhpc-defaultmap-firstprivate-explicit-map.f90

@@ -0,0 +1,45 @@
+! NVHPC 25.11, NVIDIA A100 80GB PCIe (wingtip, sm_80), both memory modes:
+! with defaultmap(firstprivate) on a target construct, the arrays and
+! scalars the construct maps EXPLICITLY (map(from: b), map(tofrom:
+! host_flag)) are not copied back: the host sees b and host_flag unchanged.
+! Spec: "The defaultmap clause determines the implicit data-mapping or
+! data-sharing attribute of certain variables" (5.2 §5.8.7 p.161); "When
+! specified, explicit data-environment attribute clauses on target
+! directives determine the attributes" of the variables they name (5.2
+! §5.8.1 p.148).
+! Vendor: "The defaultmap clause is supported using OpenMP 5.0 semantics"
+! (HPC Compilers User's Guide 25.11 §7.4, 2.12.5).
+! Expected: "sum 2144 host_flag 0".
+! Observed (2026-10-24, nvfortran 25.11-0, -O2, OMP_TARGET_OFFLOAD=
+! mandatory, two runs, the same): "sum 0 host_flag 1".
+! Found by the catalog (omp50/52/60-clause-defaultmap-firstprivate: their
+! cells read ran_on_host=1 check=fail; confirmer R20-runtime-bug); reduced
+! by hand.
+! NVHPC 26.9 (26.9-0, the latest release; rerun 2026-10-24 on wingtip with
+! the same flags): still present -- the same: "sum 0 host_flag 1", both modes.
+! Fix (2026-10-24): rerun on 25.11 and 26.9 in both memory modes,
+! each with its own runtime libraries (LD_LIBRARY_PATH = the release's
+! compilers/lib; the first 26.9 runs had loaded 25.11's): still present
+! on both releases, the same output.
+! NVHPC: nvfortran -mp=gpu -gpu=cc80 -gpu=mem:separate -O2
+! Run:   OMP_TARGET_OFFLOAD=mandatory ./a.out
+program p
+  use omp_lib, only: omp_is_initial_device
+  implicit none
+  integer :: b(64), host_flag, i, c
+  b = 0
+  host_flag = 1
+  c = 1
+  !$omp target map(from: b) map(tofrom: host_flag) defaultmap(firstprivate)
+    host_flag = merge(1, 0, omp_is_initial_device())
+    do i = 1, 64
+      b(i) = i + c
+    end do
+  !$omp end target
+  print *, 'sum', sum(b), 'host_flag', host_flag
+end program p
+! site:
+! title: nvfortran -mp=gpu: defaultmap(firstprivate) drops the copy-back of explicitly mapped variables
+! control: ../vendor/checks/src/nvhpc/control/nvhpc-defaultmap-firstprivate-explicit-map-control.f90 defaultmap(firstprivate)
+! + removed
+! end site

offload/_root/data/findings/nvhpc-defaultmap-from-allocatable-indexing.f90

@@ -0,0 +1,60 @@
+! NVHPC 25.11, NVIDIA A100 80GB PCIe (wingtip, sm_80), both memory modes
+! (-gpu=mem:separate and mem:managed): defaultmap(from) (likewise defaultmap(alloc)) on a
+! target construct breaks the indexing of allocatable arrays the construct
+! maps EXPLICITLY: b(i) = a(i) stores the wrong elements.
+! Spec: "The defaultmap clause determines the implicit data-mapping or
+! data-sharing attribute of certain variables" (5.2 §5.8.7 p.161) and
+! "When specified, explicit data-environment attribute clauses on target
+! directives determine the attributes" of the variables they name (5.2
+! §5.8.1 p.148): a and b keep map(to:) and map(from:).
+! Vendor: "The defaultmap clause is supported using OpenMP 5.0 semantics"
+! (HPC Compilers User's Guide 25.11 §7.4, 2.12.5 Target Construct).
+! Expected: "b(1) 1 b(64) 64 sum 2080".
+! Observed (2026-10-24, nvfortran 25.11-0, -O2, two runs, the same):
+! "b(1) 2 b(64) 0 sum 2079" (b shifted by one element); with
+! defaultmap(alloc): "b(1) 0 b(64) 64 sum 2079"; with defaultmap(tofrom)
+! or without defaultmap, and with fixed-size arrays: correct. The
+! array descriptor of an allocatable looks mapped by the defaultmap
+! behaviour (from: not copied to the device).
+! Found by the catalog (omp50/52/60-clause-defaultmap-from: confirmer
+! R20-runtime-bug); reduced by hand.
+! NVHPC 26.9 (26.9-0, the latest release; rerun 2026-10-24 on wingtip with
+! the same flags): still present -- the same: "b(1) 2 b(64) 0 sum 2079", in separate and in managed memory (25.11 likewise in both
+! modes).
+! Fix (2026-10-24): rerun on 25.11 and 26.9 in both memory modes,
+! each with its own runtime libraries (LD_LIBRARY_PATH = the release's
+! compilers/lib; the first 26.9 runs had loaded 25.11's): still present
+! on both releases, the same output.
+! Coverage-parity fuzz, stratum c1 (2026-11-03): program par-c1-nvhpc-nvhpc269:1572 (a target
+! region with defaultmap(alloc: scalar) that indexes explicitly mapped allocatable arrays) gives a
+! wrong checksum on 25.11 and 26.9 (rows
+! results/parity/wingtip/results/fuzz/par-c1-nvhpc-nvhpc269/programs.jsonl; the gate confirms
+! both cells in a-d, results/parity/wingtip/results/parity/gate/fuzz/verdicts.nvhpc-topup.jsonl).
+! Without the defaultmap clause it gives the expected checksum; a reduced form reads a(i+1) for
+! a(i) of an allocatable array, mapped implicitly or explicitly, and is correct with
+! defaultmap(tofrom: scalar), defaultmap(firstprivate: scalar) or an explicit-shape array: this
+! appears to be the shift of this finding, reached through the scalar category, which names no
+! array (exploration runs on both releases, no result rows).
+! No separate finding; if the scalar-category form holds up in rows, the title and control of this
+! finding are narrower than the defect.
+! NVHPC: nvfortran -mp=gpu -gpu=cc80 -gpu=mem:separate -O2
+! Run:   OMP_TARGET_OFFLOAD=mandatory ./a.out
+program p
+  implicit none
+  integer, allocatable :: a(:), b(:)
+  integer :: i
+  allocate(a(64), b(64))
+  a = [(i, i = 1, 64)]
+  b = 0
+  !$omp target map(to: a) map(from: b) defaultmap(from)
+    do i = 1, 64
+      b(i) = a(i)
+    end do
+  !$omp end target
+  print *, 'b(1)', b(1), 'b(64)', b(64), 'sum', sum(b), '(expected 1 64 2080)'
+end program p
+! site:
+! title: nvfortran -mp=gpu: defaultmap(from) or defaultmap(alloc) shifts explicitly mapped allocatable arrays
+! control: ../vendor/checks/src/nvhpc/control/nvhpc-defaultmap-from-allocatable-indexing-control.f90 defaultmap(tofrom) instead of
+! + defaultmap(from)
+! end site

offload/_root/data/findings/nvhpc-depend-inoutset-ignored.f90

@@ -0,0 +1,64 @@
+! NVHPC 25.11, NVIDIA A100 80GB PCIe (wingtip, sm_80), both memory
+! modes: the inoutset and mutexinoutset dependence types on target nowait
+! constructs are accepted silently and ignored, giving a wrong answer: a
+! later target nowait with depend(in: w) runs before the first one has
+! written w. NVHPC documents both types as outside its subset (below), so
+! the defect is an unsupported dependence type accepted without the
+! message the guide promises, not a documented feature failing.
+! Spec: "For the in task-dependence-type, if the storage location of at
+! least one of the list items matches the storage location of a list item
+! appearing in a depend clause with an out, inout, mutexinoutset, or
+! inoutset task-dependence-type on a construct from which a sibling task
+! was previously generated, then the generated task will be a dependent
+! task of that sibling task" (5.2 §15.9.5 p.323).
+! Vendor (HPC Compilers User's Guide 25.11 and 26.9 §7.4): depend on the
+! target constructs "is supported as described in 2.17.11" (2.12.3-2.12.6),
+! and 2.17.11: "The dependence types in, out, and inout are supported. The
+! dependence types mutexinoutset and depobj, dependence modifier
+! iterator(iters), depend(source), and depend(sink:vector) are not
+! supported." (inoutset is in neither list); §7: "Where ignoring such
+! features is not possible, or could result in ambiguous or incorrect
+! execution, the compilers emit appropriate error messages at compile- or
+! run-time": no message, at compile or run time.
+! Expected: "sum(b) 2080".
+! Observed (2026-10-24, nvfortran 25.11-0, -O2, two runs, the same):
+! "sum(b) 0" with depend(inoutset: w) and with depend(mutexinoutset: w);
+! with depend(out: w): 2080 (correct).
+! Found by the catalog (omp52/60-clause-depend-inoutset, omp50/52/60-
+! clause-depend-mutexinoutset: confirmer R20-runtime-bug); reduced by hand.
+! NVHPC 26.9 (26.9-0, the latest release; rerun 2026-10-24 on wingtip with
+! the same flags): still present -- the same: "sum(b) 0", both modes.
+! Fix (2026-10-24): rerun on 25.11 and 26.9 in both memory modes,
+! each with its own runtime libraries (LD_LIBRARY_PATH = the release's
+! compilers/lib; the first 26.9 runs had loaded 25.11's): still present
+! on both releases, the same output.
+! NVHPC: nvfortran -mp=gpu -gpu=cc80 -gpu=mem:separate -O2
+! Run:   OMP_TARGET_OFFLOAD=mandatory ./a.out
+program p
+  implicit none
+  integer :: w(64), b(64), j, sp, spin(1)
+  w = 0
+  b = 0
+  !$omp target nowait map(tofrom: w) map(from: spin) depend(inoutset: w)
+    sp = 1
+    do j = 1, 20000000
+      sp = mod(7*sp + j, 1000003)
+    end do
+    spin(1) = sp
+    do j = 1, 64
+      w(j) = j
+    end do
+  !$omp end target
+  !$omp target nowait map(to: w) map(from: b) depend(in: w)
+    do j = 1, 64
+      b(j) = w(j)
+    end do
+  !$omp end target
+  !$omp taskwait
+  print *, 'sum(b)', sum(b), '(expected 2080)'
+end program p
+! site:
+! title: nvfortran -mp=gpu: depend(inoutset) on target nowait accepted and ignored, wrong answer
+! control: ../vendor/checks/src/nvhpc/control/nvhpc-depend-inoutset-ignored-control.f90 depend(out: w) instead of
+! + depend(inoutset: w)
+! end site

offload/_root/data/findings/nvhpc-dist-schedule-chunk-illegal-address.f90

@@ -0,0 +1,52 @@
+! NVHPC 25.11, NVIDIA A100 80GB PCIe (wingtip, sm_80), both memory modes: a
+! target teams distribute parallel do with num_teams(4) and
+! dist_schedule(static, 4) ends at run time with "Accelerator Fatal Error:
+! call to cuMemcpyDtoHAsync returned error 700 (CUDA_ERROR_ILLEGAL_ADDRESS):
+! Illegal address during kernel execution" (exit status 1).
+! Spec: with dist_schedule(static, chunk_size) the iterations are divided
+! into chunks that "are assigned to the initial teams of the league in a
+! round-robin fashion in the order of the initial team number" (5.2
+! §11.6.1 p.256); the program is legal.
+! Vendor: "The private, firstprivate, collapse, and dist_schedule(static [
+! ,chunksize]) clauses are supported" (HPC Compilers User's Guide 25.11
+! §7.4, 2.9.4 Distribute Directives).
+! Expected: "sum 2080".
+! Observed (2026-10-24, nvfortran 25.11-0, -O2, OMP_TARGET_OFFLOAD=
+! mandatory, two runs, the same): "Failing in Thread:1", the illegal
+! address error at line 10, exit status 1. Without dist_schedule the
+! program is correct.
+! Found by the catalog (omp50/52/60-clause-dist_schedule-chunk_size:
+! confirmer R20-runtime-bug); reduced by hand. The C port of the catalog
+! program does not compile: nvc does not finish (compile timeout, 900 s;
+! nvhpc-c-dist-schedule-chunk-compile-hang.c).
+! NVHPC 26.9 (26.9-0, the latest release; rerun 2026-10-24 on wingtip with
+! the same flags): still present -- the same: the illegal-address abort, exit 1, both modes.
+! Fix (2026-10-24): rerun on 25.11 and 26.9 in both memory modes,
+! each with its own runtime libraries (LD_LIBRARY_PATH = the release's
+! compilers/lib; the first 26.9 runs had loaded 25.11's): still present
+! on both releases, the same output.
+! Coverage-parity fuzz, stratum c1 (2026-11-03): programs par-c1-nvhpc-nvhpc269:1052
+! (dist_schedule(static, 1) on teams distribute parallel do in a target region) and :1389
+! (dist_schedule(static, 2) on target teams distribute parallel do simd) end with this message
+! (cuMemcpyDtoHAsync, error 700) on 25.11 and 26.9 (rows
+! results/parity/wingtip/results/fuzz/par-c1-nvhpc-nvhpc269/programs.jsonl; the gate confirms
+! all four cells in a-d, results/parity/wingtip/results/parity/gate/fuzz/verdicts.nvhpc-topup.jsonl).
+! With dist_schedule(static) in place of the chunked form each gives the expected checksum
+! (exploration runs on both releases). No separate finding.
+! NVHPC: nvfortran -mp=gpu -gpu=cc80 -gpu=mem:separate -O2
+! Run:   OMP_TARGET_OFFLOAD=mandatory ./a.out
+program p
+  implicit none
+  integer :: b(64), i
+  b = 0
+  !$omp target teams distribute parallel do map(from: b) num_teams(4) &
+  !$omp& dist_schedule(static, 4)
+  do i = 1, 64
+    b(i) = i
+  end do
+  print *, 'sum', sum(b)
+end program p
+! site:
+! title: nvfortran -mp=gpu: dist_schedule(static, 4) on target teams distribute parallel do ends in CUDA_ERROR_ILLEGAL_ADDRESS
+! control: ../vendor/checks/src/nvhpc/control/nvhpc-dist-schedule-chunk-illegal-address-control.f90 dist_schedule(static, 4) removed
+! end site

offload/_root/data/findings/nvhpc-managed-acc-shutdown-host-access.f90

@@ -0,0 +1,42 @@
+! NVHPC 25.11, NVIDIA A100 80GB PCIe (wingtip, sm_80), managed memory
+! (-gpu=mem:managed): after the OpenACC shutdown directive a HOST access to
+! an allocatable array ends the program with SIGSEGV; the same program is
+! correct in separate memory (the compiler's default).
+! Spec: "The shutdown directive shuts down the connection to the given
+! device or devices of the given device type, and frees any associated
+! runtime resources. This ends all data lifetimes in device memory"
+! (OpenACC 3.4 §2.14.2 p.86). It ends device data lifetimes; the host array
+! is host data of the program (no data clause names it here), so reading it
+! on the host afterwards is defined. Managed memory is NVHPC's mode in which
+! "Dynamically allocated host data are placed in CUDA Managed Memory" (HPC
+! Compilers User's Guide 25.11 §5.4): the program's own host allocation
+! becomes a runtime resource that shutdown frees.
+! Expected: "after shutdown" and "sum 64", exit 0.
+! Observed (2026-10-24, nvfortran 25.11-0, -O2, two runs, the same):
+! - -gpu=mem:separate: "after shutdown", "sum 64", exit 0 (correct);
+! - -gpu=mem:managed: no output, exit status 139 (SIGSEGV; the buffered
+!   output is lost).
+! Found by the catalog: acc34-directive-shutdown is correct in separate
+! memory and crashes in managed memory (catalog/mode_differences.yaml
+! nvhpc_entries, class managed_failure); reduced by hand to this program.
+! NVHPC 26.9 (26.9-0, the latest release; rerun 2026-10-24 on wingtip with
+! the same flags): still present -- the same: managed memory SIGSEGV (exit 139), separate correct.
+! Fix (2026-10-24): rerun on 25.11 and 26.9 in both memory modes,
+! each with its own runtime libraries (LD_LIBRARY_PATH = the release's
+! compilers/lib; the first 26.9 runs had loaded 25.11's): still present
+! on both releases, the same output.
+! NVHPC: nvfortran -acc=gpu -gpu=cc80 -gpu=mem:managed -O2
+! Run:   ./a.out
+program p
+  implicit none
+  integer, allocatable :: a(:)
+  allocate(a(64))
+  a = 1
+  !$acc shutdown
+  print *, 'after shutdown'
+  print *, 'sum', sum(a)
+end program p
+! site:
+! title: nvfortran -acc -gpu=mem:managed: host access to an allocatable after !$acc shutdown ends in SIGSEGV
+! control: ../vendor/checks/src/nvhpc/control/nvhpc-managed-acc-shutdown-host-access-control.f90 the shutdown directive removed
+! end site

offload/_root/data/findings/nvhpc-parallel-if-in-target-nvvm-ice.f90

@@ -0,0 +1,60 @@
+! NVHPC 25.11, NVIDIA A100 80GB PCIe (wingtip, sm_80), both memory modes
+! (-gpu=mem:separate and -gpu=mem:managed): an if clause on a parallel do
+! nested in a target region makes the device compiler fail
+! (nvvmCompileProgram: failed with error 9: NVVM_ERROR_COMPILATION, "parse
+! invalid forward reference to function 'nvkernel_MAIN__...' with wrong
+! type!") instead of compiling the program or giving a diagnostic.
+! Spec: the if clause is one of the inputs that "are used to determine the
+! number of threads to use in the region" (5.2 §10.1.1 p.226); an if clause
+! that evaluates to false gives a team of one thread. The program is legal.
+! Vendor: "The if and copyin clauses are supported only for CPU targets;
+! the compiler emits an error for GPU targets" (HPC Compilers User's Guide
+! 25.11 §7.4, 2.6 Parallel Construct): documented unsupported, so the bug
+! is the internal device-compiler failure where a diagnostic is promised.
+! The guide's §2.20 sentence "nested teams or parallel regions in a
+! target region are not supported" is read as a parallel region nested in
+! another parallel (or teams) region inside a target region; here the
+! parallel do is the only parallel region in the target region.
+! Expected: "sum 2080" (or a diagnostic naming the if clause).
+! Observed (2026-10-24, nvfortran 25.11-0, -O2): compile exit status 2 with
+! the NVVM error and "NVFORTRAN-W-0155-Compiler failed to translate
+! accelerator region (see -Minfo messages): Device compiler exited with
+! error status code"; the same for the C port (nvc) of the catalog program.
+! Found by the catalog (omp50/52/60-clause-if, omp52/60-c-clause-if:
+! confirmer R10-compile-ice); reduced by hand.
+! NVHPC 26.9 (26.9-0, the latest release; rerun 2026-10-24 on wingtip with
+! the same flags): still present -- the same NVVM failure, now after a new warning "NVFORTRAN-W-0155-Passing external procedure as
+! argument in OpenACC/OpenMP device routine context - runtime behavior may be unsupported"; both modes.
+! Fix (2026-10-24): rerun on 25.11 and 26.9 in both memory modes,
+! each with its own runtime libraries (LD_LIBRARY_PATH = the release's
+! compilers/lib; the first 26.9 runs had loaded 25.11's): still present
+! on both releases, the same output.
+! Coverage-parity fuzz, stratum c1 (2026-11-03): program par-c1-nvhpc-nvhpc269:2306, a
+! parallel do with proc_bind(spread) and if(parallel: lpar) in a target region, stops the same way
+! on 25.11 and 26.9 (nvvmCompileProgram: failed with error 9: NVVM_ERROR_COMPILATION; rows
+! results/parity/wingtip/results/fuzz/par-c1-nvhpc-nvhpc269/programs.jsonl; the gate confirms both
+! cells in a-d, results/parity/wingtip/results/parity/gate/fuzz/verdicts.nvhpc-topup.jsonl). New
+! facet: the if clause with the parallel directive-name modifier reaches the NVVM failure too, while
+! six other c1 cells with if(parallel: ...) get the documented diagnostic "GPU target doesn't
+! support 'if' clauses for managing parallel region". No separate finding.
+! NVHPC: nvfortran -mp=gpu -gpu=cc80 -gpu=mem:separate -O2
+! Run:   OMP_TARGET_OFFLOAD=mandatory ./a.out
+program p
+  implicit none
+  integer :: a(64), i
+  logical :: use_par
+  use_par = .false.
+  a = 0
+  !$omp target map(tofrom: a)
+    !$omp parallel do if(use_par)
+    do i = 1, 64
+      a(i) = i
+    end do
+  !$omp end target
+  print *, 'sum', sum(a)
+end program p
+! site:
+! title: nvfortran/nvc -mp=gpu: if clause on a parallel loop in a target region gives an internal NVVM error instead of the
+! + documented diagnostic
+! control: ../vendor/checks/src/nvhpc/control/nvhpc-parallel-if-in-target-nvvm-ice-control.f90 the if clause removed
+! end site

offload/_root/data/findings/oop/afar-final-dealloc-device-link.f90

@@ -0,0 +1,85 @@
+! # Finding (fortran-oop): amdflang: DEALLOCATE of an allocatable finalizable object in device code fails at the device link
+!
+! - toolchains and modes that fail: afar (AFAR: copy, unified); -O2
+! - build: amdflang -fopenmp --offload-arch=gfx942 -fopenmp-version=52 -O2
+! - failure: rejected (link_undefined_symbol, the program's own object); OMP_TARGET_OFFLOAD=mandatory
+! - observed: `ld.lld: error: undefined symbol: flang_rt_verbose_abort(char const*, ...)` at the device link, both modes: the
+!   device code of the DEALLOCATE (with its finalization) calls a flang runtime routine that has no device version
+! - expected: compiles; `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 in both modes (results/oop/main/rows.part*.jsonl,
+!   results/oop/probe/ctl2.*.final-local.*.jsonl)
+! - other families: CCE 19/20 stop the device thread at the DEALLOCATE and CCE 21 aborts (cce-final-dealloc-device-abort.f90); GCC
+!   16.2 correct. The confirmer's signature also matches afar-udr-derived-type-link.f90 (the same undefined symbol, from a declare
+!   reduction with a structure-constructor combiner); the triggers differ, so this is a finding of its own
+! - 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 (R10b-own-link-or-hang) 2
+! - programs (1): oop-assignfinal-final-dealloc (offload/engine/oop_gen.py; this file is the first one)
+! - legality: the rules and the front ends of the other families (AFAR's own front end is not its witness): CCE compiles it (its
+!   failure is at run time) and NVHPC's verdict is no verdict (an unsupported runtime routine, results/oop/main/witness.jsonl);
+!   tools/campaigns/oop.py legality: legal for AFAR
+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 fails at the link
+! summary: A declare target subroutine allocates and deallocates a local allocatable object of a type with a final subroutine.
+! + AMD's flang fails at the device link: flang_rt_verbose_abort is undefined. The same type as a non-allocatable local is finalized
+! + correctly on the device.
+! control: oop/controls/final-local.f90 a non-allocatable local of the same finalizable type (no DEALLOCATE)
+! end site

offload/_root/data/findings/oop/afar-pdt-length-parameter-not-implemented.f90

@@ -0,0 +1,65 @@
+! # Finding (fortran-oop): amdflang: a derived type with a length type parameter in a target region is not implemented
+!
+! - toolchains and modes that fail: afar (AFAR: copy, unified); -O2
+! - build: amdflang -fopenmp --offload-arch=gfx942 -fopenmp-version=52 -O2
+! - failure: rejected (not_implemented); OMP_TARGET_OFFLOAD=mandatory
+! - observed: `flang/lib/Lower/ConvertType.cpp:470: not yet implemented` for the length parameter, both modes
+! - expected: compiles; `r1= 16 r2= 1496`
+! - rule: 5.2 §5.8.3 p.155 l.5-7 (type parameters of mapped list items)
+! - 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 AFAR 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: CCE rejects them too (cce-pdt-default-mapper-rejected.f90); GCC 16.2 aborts at run time
+! - 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): unsupported (R05-unsupported) 8
+! - 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: the rules accept every program; the front ends of the other families: CCE compiles none (its own rejection,
+!   cce-pdt-default-mapper-rejected.f90) and NVHPC's verdict is in results/oop/main/witness.jsonl; the not-implemented message is
+!   AFAR's own statement of a missing feature
+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: length type parameters of derived types are not implemented in offload code
+! summary: AMD's flang reports 'not yet implemented' for a parameterized derived type with a length type parameter used in a
+! + target region. A kind type 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-class-is-device-link.f90

@@ -0,0 +1,86 @@
+! # Finding (fortran-oop): SELECT TYPE with a CLASS IS guard in device code fails to link (_EXTENDS_TYPE_OF)
+!
+! - 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: _EXTENDS_TYPE_OF`, every CCE release, both modes
+! - expected: compiles; `r1= 121`
+! - rule: Fortran 2018 11.1.11 (CLASS IS guards); no OpenMP restriction on SELECT TYPE in device procedures
+! (section 6)
+! - same-compiler control: TYPE IS guards only (oop-poly-select-type) link (and then take the wrong branch:
+!   cce-select-type-guard-not-taken.f90)
+! - other families: AFAR correct; GCC 16.2 rejects it (gcc-vtab-not-marked-for-offload.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 (R10b-own-link-or-hang) 8
+! - programs (1): oop-poly-class-is (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 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 tag(s, t)
+    !$omp declare target
+    class(base_t), intent(in) :: s
+    integer, intent(out) :: t
+    t = 0
+    select type (s)
+      class is (base_t)
+        t = 1
+      type is (ext2)
+        t = 2
+    end select
+  end subroutine tag
+end module oop_m
+
+program oop
+  use omp_lib
+  use oop_m
+  implicit none
+  integer :: host_flag
+  logical :: ok
+  integer :: r1
+  type(ext1) :: e1
+  type(ext2) :: e2
+  type(base_t) :: b0
+  integer :: t1, t2, t3
+  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) map(from: t1, t2, t3)
+  call tag(e1, t1)
+  call tag(e2, t2)
+  call tag(b0, t3)
+  !$omp end target
+  r1 = 100 * t1 + 10 * t2 + t3
+  ok = .true.
+  ok = ok .and. (r1 == 121)
+  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 CLASS IS guard of SELECT TYPE in device code fails at the link
+! summary: SELECT TYPE with a CLASS IS guard in a declare target subroutine called in a target region fails at the device link on
+! + CCE 19, 20 and 21 (undefined _EXTENDS_TYPE_OF). AFAR runs it correctly.
+! end site
+! spec (requirement): the base language is Fortran 2003, 2008 and 2018, and only the few Fortran features listed in the
+!   base-language section have unspecified behavior (SELECT TYPE with a CLASS IS guard is not one of them; its semantics are the
+!   Fortran standard's, with no OpenMP text of its own); a declare target procedure must be executable on a device.
+! "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)
+! "Declare target directives apply to procedures and/or variables to ensure that they can be executed or accessed on a device."
+!   (5.2 §7.8 p.204 l.16-17)
+! spec (this program): the declare target subroutine tag uses SELECT TYPE with a CLASS IS guard and is called in a target
+!   region; CCE 19, 20 and 21 build it but fail at the link (undefined symbol _EXTENDS_TYPE_OF), so the procedure cannot be
+!   executed on the device.