offtarget 0.1.0__py3-none-any.whl

offload/_root/data/findings/nested/gcc-fortran-pointer-component-alloc-bounds-lost.f90

@@ -0,0 +1,62 @@
+! # Finding (nested-data): GCC: a pointer component mapped alloc and written on the device comes back with the wrong values
+! # (bounds of the attached descriptor not set)
+!
+! - toolchains and modes that fail: gcc_g90 (GCC 16.2.0), gcc_sm80 (GCC 16.2.0); modes: copy; -O2
+! - build: gfortran -fopenmp -foffload=amdgcn-amdhsa -foffload-options=amdgcn-amdhsa=-march=gfx90a -O2 (gcc_g90); gfortran -fopenmp
+!   -foffload=nvptx-none -foffload-options=nvptx-none=-march=sm_80 -foffload-options=nvptx-none=-latomic -O2 (gcc_sm80)
+! - failure: wrong_answer (check=fail)
+! - observed: `tot= 504`, `s= 900` with `check=fail`
+! - expected: compiles and prints `tot= 4028`, `s= 900` with `check=pass` (the model of the program: the sum of the
+!   written values)
+! - rule: on entry the corresponding pointer "is associated with a pointer target that has the same rank and bounds as
+!   the pointer target of the original pointer, such that the corresponding list item can be accessed through the
+!   pointer in a target region" (5.2 §5.8.3 p.152 l.11-13); the structure is entered with map(alloc:), so its descriptor
+!   is not initialized by a transfer and has to be set by the attach
+! - same-compiler control: controls/g2-ctl-entered-to.f90 (one change from this file; correct on gcc_g90 (GCC 16.2.0), gcc_sm80 (GCC
+!   16.2.0); rows results/nested/red/red1.jsonl, results/nested/red/tuo2.jsonl, results/nested/red/wgs.jsonl,
+!   results/nested/red/wnv.jsonl); controls/g2-ctl-allocatable.f90 (one change from this file; correct on gcc_g90 (GCC 16.2.0),
+!   gcc_sm80 (GCC 16.2.0); rows results/nested/red/red1.jsonl, results/nested/red/wgs.jsonl, results/nested/red/wnv.jsonl)
+! - other families: afar (AFAR 24.3.0), cce19 (CCE 19.0.0), cce20 (CCE 20.0.2), cce21 (CCE 21.0.3), cce21_4 (CCE 21.0.4), nvhpc
+!   (NVHPC 25.11), nvhpc269 (NVHPC 26.9) run the file correctly (rows results/nested/red/tuo2.jsonl, results/nested/red/wnv.jsonl,
+!   site rows, check case site-nested--gcc-fortran-pointer-component-alloc-bounds-lost)
+! - legality: the rules (offload.engine.rules) accept it, AFAR's flang front end accepts it
+program t
+  use omp_lib
+  implicit none
+  type :: n0
+    integer :: s = 0
+    integer, pointer :: a(:) => null()
+  end type n0
+  type(n0) :: r
+  integer :: q, hf, tot
+  logical :: ok
+  hf = 1
+  !$omp target map(from: hf)
+  hf = merge(1, 0, omp_is_initial_device())
+  !$omp end target
+  allocate(r%a(8))
+  r%s = -1
+  r%a = -1
+  !$omp target enter data map(alloc: r)
+  !$omp target enter data map(alloc: r%a)
+  !$omp target
+    do q = 1, 8
+      r%a(q) = 500 + q - 1
+    end do
+    r%s = 900
+  !$omp end target
+  !$omp target exit data map(from: r%a)
+  !$omp target exit data map(from: r)
+  tot = sum(r%a)
+  ok = tot == 4028 .and. r%s == 900
+  print '(a,i0)', 'tot= ', tot
+  print '(a,i0)', 's= ', r%s
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', hf, ' check=', merge('pass', 'fail', ok)
+end program t
+
+! site:
+! title: GCC Fortran: pointer component entered with alloc comes back with wrong values
+! summary: GCC returns wrong values for a Fortran pointer component entered with map(alloc:).
+! control: nested/controls/g2-ctl-entered-to.f90 one change from the finding; correct on gcc_g90, gcc_sm80
+! control: nested/controls/g2-ctl-allocatable.f90 one change from the finding; correct on gcc_g90, gcc_sm80
+! end site

offload/_root/data/findings/nested/gcc-fortran-root-and-element-pointer-components-ice.f90

@@ -0,0 +1,77 @@
+! # Finding (nested-data): GCC ICE in gimplify_adjust_omp_clauses: a pointer component of the root and the pointer components
+! # of the elements of an allocatable component array in one map list
+!
+! - toolchains and modes that fail: gcc_g90 (GCC 16.2.0), gcc_sm80 (GCC 16.2.0); modes: copy; -O2
+! - build: gfortran -fopenmp -foffload=amdgcn-amdhsa -foffload-options=amdgcn-amdhsa=-march=gfx90a -O2 (gcc_g90); gfortran -fopenmp
+!   -foffload=nvptx-none -foffload-options=nvptx-none=-march=sm_80 -foffload-options=nvptx-none=-latomic -O2 (gcc_sm80)
+! - failure: ice
+! - observed: `Please submit a full bug report, with preprocessed source (by using -freport-bug).`; identical signature on 2 of 2
+!   failing cells
+! - expected: compiles and prints `tot= 24` with `check=pass`
+! - rule: pointer components are list items when they appear in a map clause ("The list items that appear in a map
+!   clause may include array sections and structure elements", 5.2 §5.8.3 p.151 l.13); the construct names a pointer
+!   component of the root and the pointer components of the elements of an allocatable array component, none of them the
+!   base pointer of another item (5.2 §5.8.3 p.152 l.1-3)
+! - same-compiler control: controls/g5-ctl-element-pointers-only.f90 (one change from this file; correct on gcc_g90 (GCC 16.2.0),
+!   gcc_sm80 (GCC 16.2.0); rows results/nested/red/gate_abd.jsonl, results/nested/red/gate_c.jsonl, results/nested/red/red3.jsonl,
+!   results/nested/red/tuo7.jsonl, results/nested/red/wgs.jsonl, results/nested/red/wnv.jsonl);
+!   controls/g5-ctl-root-pointer-only.f90 (one change from this file; correct on gcc_g90 (GCC 16.2.0), gcc_sm80 (GCC 16.2.0); rows
+!   results/nested/red/gate_abd.jsonl, results/nested/red/gate_c.jsonl, results/nested/red/red3.jsonl,
+!   results/nested/red/tuo7.jsonl, results/nested/red/wgs.jsonl, results/nested/red/wnv.jsonl)
+! - other families: afar (AFAR 24.3.0), cce19 (CCE 19.0.0), cce20 (CCE 20.0.2), cce21 (CCE 21.0.3), cce21_4 (CCE 21.0.4), nvhpc
+!   (NVHPC 25.11), nvhpc269 (NVHPC 26.9) run the file correctly in managed mode (rows results/nested/red/tuo7.jsonl,
+!   results/nested/red/wnv.jsonl, site rows, check case site-nested--gcc-fortran-root-and-element-pointer-components-ice); nvhpc
+!   (NVHPC 25.11), nvhpc269 (NVHPC 26.9) fail it another way in copy mode, e.g. `Failing in Thread:1`
+! - gate and confirmer: campaign gate of the programs below: 4 cells, 4 confirmed in the four environments (a-d; (c) on another node
+!   or GPU; rows results/nested/main/gate_reruns.part.tioga37.2711328.jsonl,
+!   results/nested/main/gate_reruns.part.tioga39.351539.jsonl,
+!   results/nested/main/gate_reruns.part.wingtip.3374144.jsonl,
+!   results/nested/main/gate_reruns.part.wingtip.3386107.jsonl,
+!   results/nested/main/gate_reruns.part.wingtip.3582436.jsonl,
+!   results/nested/main/gate_reruns.part.wingtip.3637854.jsonl,
+!   results/nested/main/rows.part.tioga37.2691037.jsonl, results/nested/main/rows.part.wingtip.3363229.jsonl,
+!   results/nested/main/rows.part.wingtip.3363230.jsonl)
+! - programs (2): nd-f-omp-tdata_nested-chain-d3-0fae50d2, nd-f-omp-tdata_nested-chain-d3-b0edb43f
+! - legality: the rules (offload.engine.rules) accept it and AFAR's flang front end accepts it
+program t
+  use omp_lib
+  implicit none
+  type :: n1
+    integer, pointer :: a(:) => null()
+  end type n1
+  type :: n0
+    integer, pointer :: a(:) => null()
+    type(n1), allocatable :: nx(:)
+  end type n0
+  type(n0) :: r
+  integer :: q, hf, tot
+  logical :: ok
+  hf = 1
+  !$omp target map(from: hf)
+  hf = merge(1, 0, omp_is_initial_device())
+  !$omp end target
+  allocate(r%nx(2))
+  allocate(r%a(4))
+  allocate(r%nx(1)%a(4))
+  allocate(r%nx(2)%a(4))
+  r%a = 1
+  r%nx(1)%a = 2
+  r%nx(2)%a = 3
+  !$omp target enter data map(to: r)
+  !$omp target enter data map(to: r%a) map(to: r%nx(1)%a) map(to: r%nx(2)%a)
+  !$omp target map(tofrom: tot)
+    tot = sum(r%nx(1)%a) + sum(r%nx(2)%a) + sum(r%a)
+  !$omp end target
+  !$omp target exit data map(release: r%a) map(release: r%nx(1)%a) map(release: r%nx(2)%a)
+  !$omp target exit data map(release: r)
+  ok = tot == 24
+  print '(a,i0)', 'tot= ', tot
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', hf, ' check=', merge('pass', 'fail', ok)
+end program t
+
+! site:
+! title: GCC Fortran: compiler crash on root and element pointer components in one map list
+! summary: GCC crashes in gimplify_adjust_omp_clauses on a root pointer component and element pointer components in one map list.
+! control: nested/controls/g5-ctl-element-pointers-only.f90 one change from the finding; correct on gcc_g90, gcc_sm80
+! control: nested/controls/g5-ctl-root-pointer-only.f90 one change from the finding; correct on gcc_g90, gcc_sm80
+! end site

offload/_root/data/findings/nested/nvhpc-c-pointee-before-parent-in-one-map-list-copy-fault.c

@@ -0,0 +1,55 @@
+// # Finding (nested-data): NVHPC, separate memory: a target construct that lists the pointee of a pointer member before the
+// # structure that holds the pointer fails with CUDA_ERROR_ILLEGAL_ADDRESS (the other order is correct)
+//
+// - toolchains and modes that fail: nvhpc (NVHPC 25.11), nvhpc269 (NVHPC 26.9); modes: copy; -O2
+// - build: nvc -mp=gpu -gpu=cc80 -gpu=mem:separate -O2
+// - failure: run_error
+// - observed: `exit_status: 1; without mandatory: exit_status: 1`; identical signature on 2 of 2 failing cells
+// - expected: compiles and prints `tot= 1638` with `check=pass`
+// - rule: attachment is decided on the storage of the whole construct: OpenMP 6.0 §7.9.6 p.284 l.8-10: "for which a
+//   corresponding pointer exists in the device data environment after all mappable storage blocks are mapped" (the
+//   OpenMP 5.2 text at §5.8.3 p.152 l.5-7 is worded for the state on entry and is weaker; the finding rests on the 6.0
+//   wording), so the order of the clauses of one construct does not change the result
+// - same-compiler control: controls/v2-ctl-parent-first.c (one change from this file; correct on nvhpc (NVHPC 25.11), nvhpc269
+//   (NVHPC 26.9); rows results/nested/red/red13.jsonl, results/nested/red/tuo12.jsonl, results/nested/red/wgs.jsonl,
+//   results/nested/red/wnv.jsonl); controls/v4-ctl-embedded-member.c (one change from this file; correct on nvhpc (NVHPC 25.11),
+//   nvhpc269 (NVHPC 26.9); rows results/nested/red/red13.jsonl, results/nested/red/tuo12.jsonl, results/nested/red/wgs.jsonl,
+//   results/nested/red/wnv.jsonl)
+// - other families: afar (AFAR 24.3.0), cce19 (CCE 19.0.0), cce20 (CCE 20.0.2), cce21 (CCE 21.0.3), cce21_4 (CCE 21.0.4), gcc_g90
+//   (GCC 16.2.0), gcc_sm80 (GCC 16.2.0) run the file correctly (rows results/nested/red/red13.jsonl,
+//   results/nested/red/tuo12.jsonl, results/nested/red/wgs.jsonl)
+// - gate and confirmer: 2 of 2 cells reproduce in all four environments (a-d; (c) node not recorded for every cell; rows
+//   results/nested/red/wgate_abd.jsonl, results/nested/red/wgate_c.jsonl, results/nested/red/wnv.jsonl)
+// - legality: the rules (offload.engine.rules) accept it; AFAR and CCE compile and run it correctly (front ends of two other
+//   families)
+#include <stdio.h>
+#include <stdlib.h>
+#include <omp.h>
+struct s1 { int a[8]; };
+struct s0 { int v; struct s1 *nx; };
+int main(void)
+{
+  int hf = 1, i, tot = 0, ok;
+  #pragma omp target map(from: hf)
+  hf = omp_is_initial_device() ? 1 : 0;
+  struct s0 *r = malloc(sizeof *r);
+  r->v = 10;
+  r->nx = malloc(sizeof *r->nx);
+  for (i = 0; i < 8; i++) r->nx->a[i] = 200 + i;
+  #pragma omp target map(tofrom: tot) map(to: r->nx[0:1]) map(to: r[0:1])
+  {
+    tot += r->v;
+    for (int q = 0; q < 8; q++) tot += r->nx->a[q];
+  }
+  ok = tot == 1638;
+  printf("tot= %d\n", tot);
+  printf("RESULT ran_on_host=%d check=%s\n", hf, ok ? "pass" : "fail");
+  return 0;
+}
+
+// site:
+// title: NVHPC: pointee listed before its parent in one map list faults in separate memory
+// summary: In separate memory NVHPC faults when a map list names a pointee before the structure holding the pointer.
+// control: nested/controls/v2-ctl-parent-first.c one change from the finding; correct on nvhpc, nvhpc269
+// control: nested/controls/v4-ctl-embedded-member.c one change from the finding; correct on nvhpc, nvhpc269
+// end site

offload/_root/data/findings/nested/nvhpc-c-update-from-structure-overwrites-attached-pointer-segv.c

@@ -0,0 +1,86 @@
+// # Finding (nested-data): NVHPC, separate memory: target update from() or exit data map(from:) of a structure whose pointer
+// # member is attached copies the device pointer back, and the next host access to the pointee crashes
+// # (SIGSEGV)
+//
+// - toolchains and modes that fail: nvhpc (NVHPC 25.11), nvhpc269 (NVHPC 26.9); modes: copy; -O2
+// - build: nvc -mp=gpu -gpu=cc80 -gpu=mem:separate -O2
+// - failure: crash
+// - observed: `crash: SIGSEGV; without mandatory: crash: SIGSEGV` (killed by signal SEGV); identical signature on 2 of 2 failing
+//   cells
+// - expected: compiles and prints `ha= 4028` with `check=pass`
+// - rule: OpenMP 5.2 §5.9 p.166 l.5-7: "if the corresponding list item is an attached pointer, the original list item
+//   will have the value it had on entry to the region": a target update from() of a structure must not overwrite its
+//   pointer member while the member is attached (the same holds when exit data map(from:) copies the structure back
+//   before the pointee is released)
+// - same-compiler control: controls/nu3-ctl-update-pointee-only.c (one change from this file; correct on nvhpc (NVHPC 25.11),
+//   nvhpc269 (NVHPC 26.9); rows results/nested/red/tuo23.jsonl, results/nested/red/wgs6.jsonl, results/nested/red/wnv6.jsonl);
+//   controls/ns8-ctl-enter-together-exit-split.c (one change from this file; correct on nvhpc (NVHPC 25.11), nvhpc269 (NVHPC 26.9);
+//   rows results/nested/red/tuo22.jsonl, results/nested/red/tuo23.jsonl, results/nested/red/wgs4.jsonl,
+//   results/nested/red/wnv4.jsonl); controls/ns4-ctl-two-directives-struct-then-pointee.c (one change from this file; correct on
+//   nvhpc (NVHPC 25.11), nvhpc269 (NVHPC 26.9); rows results/nested/red/red16.jsonl, results/nested/red/tuo22.jsonl,
+//   results/nested/red/wgs3.jsonl, results/nested/red/wnv3.jsonl)
+// - other families: afar (AFAR 24.3.0), cce21_4 (CCE 21.0.4), gcc_sm80 (GCC 16.2.0) run the file correctly (rows
+//   results/nested/red/tuo23.jsonl, results/nested/red/wgs6.jsonl)
+// - gate and confirmer: campaign gate of the programs below: 70 cells, 70 confirmed in the four environments (a-d; (c) on another
+//   node or GPU; rows results/nested/big/gate_reruns.part.wingtip.501872.jsonl,
+//   results/nested/big/gate_reruns.part.wingtip.501873.jsonl,
+//   results/nested/big/gate_reruns.part.wingtip.711615.jsonl,
+//   results/nested/big/gate_reruns.part.wingtip.724122.jsonl,
+//   results/nested/big/rows.part.wingtip.3693360.jsonl,
+//   results/nested/big/rows.part.wingtip.3790312.jsonl,
+//   results/nested/main/gate_reruns.part.wingtip.3582436.jsonl,
+//   results/nested/main/gate_reruns.part.wingtip.3582437.jsonl,
+//   results/nested/main/gate_reruns.part.wingtip.3637854.jsonl,
+//   results/nested/main/gate_reruns.part.wingtip.3639010.jsonl,
+//   results/nested/main/rows.part.wingtip.3363229.jsonl,
+//   results/nested/main/rows.part.wingtip.3363230.jsonl)
+// - programs (35): nd-c-omp-enter-alias-d2-0f7b1c8d, nd-c-omp-enter-alias-d2-10f14204, nd-c-omp-enter-aliassub-d2-28acd136,
+//   nd-c-omp-enter-aliassub-d2-30b02f09, nd-c-omp-enter-aliassub-d2-3cc740c1, nd-c-omp-enter-aliassub-d2-fd23e3be,
+//   nd-c-omp-enter-chain-d1-7ce2e18f, nd-c-omp-enter-chain-d2-35aa80e0, nd-c-omp-enter-chain-d2-99ea7db8,
+//   nd-c-omp-enter-chain-d2-fb177d2e, nd-c-omp-enter-chain-d3-41b3b77f, nd-c-omp-enter-chain-d3-5bca046a,
+//   nd-c-omp-enter-chain-d3-c1680a02, nd-c-omp-enter-chain-d3-c2ca2645, nd-c-omp-enter-chain-d3-fc976865,
+//   nd-c-omp-enter-diamond-d3-07ab92f3, nd-c-omp-enter-diamond-d3-41750fb6, nd-c-omp-enter-diamond-d3-5e5ed99d,
+//   nd-c-omp-enter-diamond-d3-d5e537a9, nd-c-omp-enter-diamond-d3-f1a9c3e8, nd-c-omp-enter-list-d3-e11a72cd,
+//   nd-c-omp-enter-tree-d3-e0467211, nd-c-omp-update-alias-d2-684cb0b8, nd-c-omp-update-chain-d1-a679e114,
+//   nd-c-omp-update-chain-d2-1585f8af, nd-c-omp-update-chain-d2-2b8c33ae, nd-c-omp-update-chain-d2-44c37206,
+//   nd-c-omp-update-chain-d2-60aec85d, nd-c-omp-update-chain-d2-a3703a98, nd-c-omp-update-chain-d2-b6fcbb9f,
+//   nd-c-omp-update-chain-d2-cca853ce, nd-c-omp-update-chain-d2-db6ed5e2, nd-c-omp-update-chain-d3-5648fa65,
+//   nd-c-omp-update-chain-d3-a9134361, nd-c-omp-update-chain-d3-c5604bb2
+// - legality: the rules (offload.engine.rules) accept it; AFAR and CCE compile and run it correctly (front ends of two other
+//   families)
+#include <stdio.h>
+#include <stdlib.h>
+#include <omp.h>
+enum { NM = 8 };
+struct n0 { int s; int *a; };
+int main(void)
+{
+  int hf = 1, i, ha = 0, ok;
+  struct n0 *r = calloc(1, sizeof *r);
+  #pragma omp target map(from: hf)
+  hf = omp_is_initial_device() ? 1 : 0;
+  r->a = malloc(NM * sizeof(int));
+  r->s = -1;
+  for (i = 0; i < NM; i++) r->a[i] = -1;
+  #pragma omp target enter data map(alloc: r[0:1])
+  #pragma omp target enter data map(alloc: r->a[0:8])
+  #pragma omp target teams distribute parallel for
+  for (int q = 0; q < NM; q++) r->a[q] = 500 + q;
+  #pragma omp target update from(r[0:1])
+  #pragma omp target update from(r->a[0:8])
+  #pragma omp target exit data map(delete: r->a[0:8])
+  #pragma omp target exit data map(delete: r[0:1])
+  for (i = 0; i < NM; i++) ha += r->a[i];
+  ok = ha == 4028;
+  printf("ha= %d\n", ha);
+  printf("RESULT ran_on_host=%d check=%s\n", hf, ok ? "pass" : "fail");
+  return 0;
+}
+
+// site:
+// title: NVHPC: update from of a structure overwrites its attached pointer member
+// summary: NVHPC update from() of a structure copies the device pointer back and the next host access crashes.
+// control: nested/controls/nu3-ctl-update-pointee-only.c one change from the finding; correct on nvhpc, nvhpc269
+// control: nested/controls/ns8-ctl-enter-together-exit-split.c one change from the finding; correct on nvhpc, nvhpc269
+// control: nested/controls/ns4-ctl-two-directives-struct-then-pointee.c one change from the finding; correct on nvhpc, nvhpc269
+// end site

offload/_root/data/findings/nvhpc-acc-atomic-update-sum-fort2-crash.f90

@@ -0,0 +1,53 @@
+! NVHPC 25.11 and 26.9 (nvfortran), NVIDIA A100 80GB PCIe
+! (wingtip, sm_80): the Fortran form of nvhpc-c-acc-atomic-update-sum-ice.c.
+! nvfortran rejects the OpenACC atomic update b(i) = b(i) + 2*a(i) + 1
+! ("NVFORTRAN-S-0155-Invalid atomic update expression"), and in a gang loop
+! its front end then crashes ("nvfortran-Fatal-.../maintainers/fort2 TERMINATED by
+! signal 11"), at -O0 and -O2, for -acc=gpu and -acc=multicore. In a plain
+! parallel loop on a scalar (x = x + v + 1) it only rejects ("Invalid atomic
+! update expression", "Invalid atomic region"), without the crash.
+! Spec: one Fortran form of an atomic update is "x = x operator expr", and
+! "The expression x operator expr must be mathematically equivalent to x
+! operator (expr). This requirement is satisfied if the operators in expr
+! have precedence greater than operator, or by using parentheses around expr
+! or subexpressions of expr" (OpenACC 3.4 §2.12, p.79-80).
+! b(i) + 2*a(i) + 1 is (b(i) + 2*a(i)) + 1, which is b(i) + (2*a(i) + 1) for
+! integers: the precedence and parentheses forms are sufficient, not
+! necessary, so the statement is a legal update. Written
+! b(i) = b(i) + (2*a(i) + 1) it compiles and gives sum=4224.
+! Expected: "sum=4224" (a diagnostic would at least not be a crash).
+! Observed (2026-10-25, nvfortran 25.11-0 and 26.9-0, the flags below and
+! -O0, -acc=multicore): compile exit status 2 with the two messages above,
+! on both releases (log: data/evidence/acc_c_probe/atomic/run.log, gang.f90).
+! Found by the catalog: acc34-clause-gang, acc34-clause-gang-dim and
+! acc34-directive-loop, all gang loops: the front end crashes in 11 of their
+! 12 NVHPC cells (gang-dim on 25.11 in separate memory rejects without the
+! crash; results/acc_matrix.jsonl); reduced by hand. That rejection without the crash was 1 compile in 157;
+! the other 156 (the gate's reruns and the later repeats) crashed
+! (data/evidence/gate_probe/logs/wingtip1-4.log): the 12th cell crashes too, not
+! every time.
+! NVHPC: nvfortran -acc=gpu -gpu=cc80 -gpu=mem:separate -O2
+program p
+  implicit none
+  integer, parameter :: n = 64
+  integer :: a(n), b(n), i
+  do i = 1, n
+    a(i) = i
+    b(i) = 0
+  end do
+  !$acc parallel num_gangs(4) copyin(a) copy(b)
+  !$acc loop gang
+  do i = 1, n
+    !$acc atomic update
+    b(i) = b(i) + 2*a(i) + 1
+  end do
+  !$acc end parallel
+  print '(a,i0)', 'sum=', sum(b)
+end program p
+! site:
+! title: nvc/nvfortran -acc: atomic update x = x + v + 1 rejected, then internal compiler error (nvc) or fort2 crash (nvfortran)
+! control: ../vendor/checks/src/nvhpc/control/nvhpc-acc-atomic-update-sum-fort2-crash-control.f90 b(i) = b(i) + (2*a(i) + 1), the
+! + right-hand side
+! + in parentheses
+! same_as: nvhpc-c-acc-atomic-update-sum-ice
+! end site

offload/_root/data/findings/nvhpc-c-acc-atomic-update-sum-ice.c

@@ -0,0 +1,43 @@
+// NVHPC 25.11 and 26.9 (nvc), NVIDIA A100 80GB PCIe
+// (wingtip, sm_80). nvc rejects the OpenACC atomic update x = x + v + 1
+// ("NVC++-S-0155-Invalid atomic update expression") and then stops with an
+// internal compiler error ("NVC++-F-0000-Internal compiler error. invalid ILM
+// atomic region"), at -O0 and -O2, for -acc=gpu and -acc=multicore.
+// Spec: one C form of an atomic update is "x = x binop expr", and "The
+// expression x binop expr must be mathematically equivalent to x binop
+// (expr). This requirement is satisfied if the operators in expr have
+// precedence greater than binop, or by using parentheses around expr or
+// subexpressions of expr" (OpenACC 3.4 §2.12, p.77-78). C parses the
+// statement as (x + v) + 1, which is x + (v + 1) for int: the precedence and
+// parentheses forms are sufficient, not necessary, so the statement is a
+// legal update. The same update written x = x + (v + 1) or x += v + 1
+// compiles and gives 2080.
+// Fortran: nvfortran fails the same form the same way and, in a gang loop,
+// its front end crashes (nvhpc-acc-atomic-update-sum-fort2-crash.f90).
+// Expected: "x=2080" (a diagnostic would at least not be an internal error).
+// Observed (2026-10-24, rerun 2026-10-25, nvc 25.11-0 and 26.9-0, the flags
+// below, -O0 and -acc=multicore): compile exit status 2 with the two
+// messages above, on both releases; the two other spellings print x=2080
+// (log: data/evidence/acc_c_probe/atomic/run.log, sum.c, sum_paren.c,
+// sum_compound.c).
+// Found by the catalog: the C port of acc34-clause-gang, acc34-clause-gang-dim
+// and acc34-directive-loop writes b[i - 1] = b[i - 1] + 2 * a[i - 1] + 1
+// (the -binop programs: acc34-c-clause-gang-binop, acc34-c-clause-gang-dim-
+// binop, acc34-c-directive-loop-binop); reduced by hand.
+// NVHPC: nvc -acc=gpu -gpu=cc80 -gpu=mem:separate -O2
+#include <stdio.h>
+int main(void) {
+  int x = 0;
+  #pragma acc parallel loop copy(x)
+  for (int v = 0; v < 64; v++) {
+    #pragma acc atomic update
+    x = x + v + 1;
+  }
+  printf("x=%d\n", x);
+  return 0;
+}
+// site:
+// title: nvc/nvfortran -acc: atomic update x = x + v + 1 rejected, then internal compiler error (nvc) or fort2 crash (nvfortran)
+// control: ../vendor/checks/src/nvhpc/control/nvhpc-c-acc-atomic-update-sum-ice-control.c x = x + (v + 1), the right-hand side in
+// + parentheses
+// end site

offload/_root/data/findings/nvhpc-c-dist-schedule-chunk-compile-hang.c

@@ -0,0 +1,41 @@
+// NVHPC 25.11, NVIDIA A100 80GB PCIe (wingtip, sm_80; the hang is
+// in the compile on the x86-64 host), both memory modes: nvc does not
+// finish compiling this program: its C front end (nvcpfe) runs until
+// killed (more than 60 s here; the catalog's 900 s compile timeout in both
+// memory modes). Without dist_schedule(static, 4), or with either of the
+// two `if (i == 1)` statements removed, it compiles in a second.
+// Spec: with dist_schedule(static, chunk_size) the chunks "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).
+// Expected: the compile ends (and the run prints "nt=<teams> host_flag=0").
+// Observed (2026-10-24, nvc 25.11-0, -O2, with -gpu=mem:separate and with
+// the default): `timeout 60 nvc ...` ends with status 124.
+// Found by the catalog (omp52/60-c-clause-dist_schedule-chunk_size:
+// compile_timeout, confirmer R10b-own-link-or-hang); reduced with a
+// line-deletion script, then 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: `timeout 120 nvc` ends with 124 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.
+// NVHPC: nvc -mp=gpu -gpu=cc80 -gpu=mem:separate -O2
+#include <stdio.h>
+#include <omp.h>
+int main(void) {
+  int nt = -1, host_flag = 1;
+  #pragma omp target teams distribute parallel for map(from: nt, host_flag) dist_schedule(static, 4)
+  for (int i = 1; i <= 64; i++) {
+    if (i == 1) nt = omp_get_num_teams();
+    if (i == 1) host_flag = (omp_is_initial_device() ? 1 : 0);
+  }
+  printf("nt=%d host_flag=%d\n", nt, host_flag);
+  return 0;
+}
+// site:
+// title: nvc -mp=gpu: compile does not finish with dist_schedule(static, 4) on target teams distribute parallel for
+// control: ../vendor/checks/src/nvhpc/control/nvhpc-c-dist-schedule-chunk-compile-hang-control.c dist_schedule(static, 4) removed
+// end site

offload/_root/data/findings/nvhpc-c-map-present-ignored.c

@@ -0,0 +1,42 @@
+// NVHPC 25.11, NVIDIA A100 80GB PCIe (wingtip, sm_80), both memory modes:
+// nvc accepts the present map-type modifier and ignores it: a target
+// construct with map(present, to: a) for an a that is not present runs on
+// (it maps a), where the spec requires runtime error termination.
+// Spec: "If a map clause with a present map-type-modifier appears on a
+// construct and on entry to the region the corresponding list item is not
+// present in the device data environment, runtime error termination is
+// performed" (5.2 §5.8.3 p.152).
+// Vendor: the 25.11 User's Guide names no present modifier (it lists
+// always, close and mapper: §7.4, 2.19.7); nvfortran rejects the modifier
+// at compile time (the Fortran catalog programs are rejected).
+// Expected: runtime error termination before the printf.
+// Observed (2026-10-24, nvc 25.11-0, -O2, OMP_TARGET_OFFLOAD=mandatory):
+// "continued after map(present) of an absent a: b[63]=63", exit 0.
+// The compile prints nothing (no warning, no message; exit 0) on 25.11 and
+// 26.9.
+// Found by the catalog (omp52/60-c-clause-map-present, negative probes:
+// no_error_termination; 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: the run goes on (b[63]=63), 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
+// Run:   OMP_TARGET_OFFLOAD=mandatory ./a.out
+#include <stdio.h>
+int main(void) {
+  int a[64], b[64];
+  for (int i = 0; i < 64; i++) a[i] = i;
+  #pragma omp target map(present, to: a) map(from: b)
+  for (int i = 0; i < 64; i++)
+    b[i] = a[i];
+  printf("continued after map(present) of an absent a: b[63]=%d\n", b[63]);
+  return 0;
+}
+// site:
+// title: nvc -mp=gpu: map(present, ...) of an absent variable is accepted and ignored (no error termination)
+// control: ../vendor/checks/src/nvhpc/control/nvhpc-c-map-present-ignored-control.c a enclosed in target data map(to: a), so it is
+// + present (the
+// + run must reach the printf)
+// end site

offload/_root/data/findings/nvhpc-c-ordered-in-target-nvcpfe-crash.c

@@ -0,0 +1,92 @@
+// (the reproduction gate's review queue): NVHPC 25.11 and 26.9 (nvc),
+// NVIDIA A100 80GB PCIe (wingtip, sm_80), both memory modes. nvc rejects the
+// ordered construct in a target parallel for with the ordered clause
+// ("NVC++-S-0155-for must have the ordered clause specified", at the ordered
+// region), and
+// its front end then INTERMITTENTLY crashes ("nvc-Fatal-.../maintainers/nvcpfe
+// TERMINATED by signal 11", compile exit status 2) instead of ending with
+// the diagnostic.
+// Spec: an ordered region binds to the innermost enclosing worksharing-loop
+// region; "An ordered clause with a parameter value equal to one must
+// appear on the construct that corresponds to the binding region" (5.2
+// §15.10.2 p.331 l.16-17), and "If n is not specified then the behavior is
+// as if n is specified with the same value as is specified for the collapse
+// clause on the construct" (§4.4.4 p.94 l.18-19), so the program is
+// conforming (the ordered clause applies to the for leaf of the combined
+// construct, §17.2).
+// Vendor: "The ordered block construct is supported only for CPU targets"
+// (HPC Compilers User's Guide 25.11 §7.4, 2.17.9;
+// data/index/claims/nvidia-hpc-25.11-user-guide-openmp.txt:295, and :194 for the
+// ordered clause): documented unsupported, so a diagnostic is expected
+// (rule R11c: unsupported, not a bug). Two quality-of-implementation
+// defects remain: the diagnostic's text is wrong (it says the for "must
+// have the ordered clause specified" when the clause is there), and the
+// front end then sometimes crashes. No spec text governs either: a LOWER
+// TIER finding (fix; the compile fails either way, with
+// the diagnostic printed first, as for nvhpc-parallel-if-in-target-nvvm-ice).
+// Expected: "RESULT ran_on_host=0 check=pass", or the diagnostic alone.
+// Observed (the source compiled by its absolute path in a fresh directory;
+// nvcpfe crashes / compiles, by source):
+// - nvc 26.9, -gpu=mem:separate: 31 of 58 = the logs 27 of 53 (wingtip2
+//   21/32, wingtip3 4/15, wingtip4 2/6; data/evidence/gate_probe/logs/) + the
+//   reproduction gate's 4 reruns, 4 crashes + the
+//   stored catalog row, no crash (results/widen/matrix.jsonl);
+// - nvc 25.11, -gpu=mem:managed: 26 of 52 = the logs 25 of 47 (wingtip2
+//   18/32, wingtip3 3/9, wingtip4 4/6) + the gate's 4 reruns, no crash + the
+//   stored row, a crash (in its stderr);
+// - nvc 26.9 managed: 6 of 7 (wingtip4 6/6; the stored row did not crash);
+// - nvc 25.11 separate: 0 of 7 (wingtip4 0/6; the stored row did not).
+// - A compile at a fixed path can crash or not (26.9 separate, a
+//   37-character directory: 1 of 3; 25.11 managed, a 45-character path: 1
+//   of 3), so this is not a function of the path alone; long paths crash
+//   more often (26.9: none below 17 characters of directory name in the
+//   length sweep, wingtip2.log). Compiled as the relative name prog.c in the
+//   working directory: 0 of 80 (wingtip1.log; that also changes the file
+//   name, not only the path). The scripts: data/evidence/gate_probe/wingtip/round1-4/
+//   (those runs were not inside compliant.slice: see the scripts' notes).
+// Control (same compilers, same flags): the same loop and ordered region
+// without target (a host parallel for ordered, which the guide supports)
+// compiles and prints "RESULT ran_on_host=1 check=pass" on both releases
+// and both memory modes (data/evidence/gate_probe/logs/wingtip4.log).
+// Another family: AFAR amdclang compiles the program and prints
+// "RESULT ran_on_host=0 check=pass" on MI300A at HSA_XNACK 1 and 0 and on
+// MI250X (results/widen/matrix*.jsonl). CCE craycc fails to link it
+// (__kmpc_dispatch_init_4, data/findings/catalog/cce-c-ordered-link.c).
+// Found by the widened catalog (omp52-c-w-ordered, the cells nvhpc/managed
+// and nvhpc269/copy, reproduction-gate verdict environment); the program
+// is the catalog program itself.
+// NVHPC: nvc -mp=gpu -gpu=cc80 -gpu=mem:separate -O2 $PWD/omp52-c-w-ordered.c
+#include <stdio.h>
+#include <stdbool.h>
+#include <omp.h>
+
+enum { n = 64 };
+
+int main(void) {
+  int a[n], b[n], ref[n];
+  int host_flag = 1;
+  int cnt = 0;
+  for (int i = 0; i < n; i++) {
+    a[i] = i + 1;
+    b[i] = 0;
+    ref[i] = i + 1;
+  }
+  #pragma omp target parallel for ordered map(to: a) map(tofrom: b, cnt, host_flag)
+  for (int i = 0; i < n; i++) {
+    #pragma omp ordered
+    {
+      b[cnt] = a[i];
+      cnt = cnt + 1;
+    }
+    if (i == 0) host_flag = omp_is_initial_device();
+  }
+  bool ok = true;
+  for (int i = 0; i < n; i++)
+    ok = ok && (b[i] == ref[i]);
+  ok = ok && (cnt == n);
+  printf("RESULT ran_on_host=%d check=%s\n", host_flag, ok ? "pass" : "fail");
+  return 0;
+}
+// site:
+// title: nvc rejects ordered in a target parallel for with the ordered clause, and its front end then crashes intermittently
+// end site

offload/_root/data/findings/nvhpc-c-parallel-for-firstprivate-in-target.c

@@ -0,0 +1,62 @@
+// NVHPC 25.11, NVIDIA A100 80GB PCIe (wingtip, sm_80), both memory
+// modes: nvc stops with "NVC++-F-0155-Compiler failed to translate OpenMP
+// region" on a parallel for with firstprivate nested in a target region
+// (the catalog's lastprivate program fails the same way; its
+// schedule(monotonic: dynamic) program fails because it has
+// firstprivate(mine), not because of the schedule).
+// Spec: firstprivate on a worksharing-loop construct: each new list item
+// "is initialized from the original list item that exists before the
+// construct" (5.2 §5.4.4 p.112); the program is legal.
+// Vendor: "The private, firstprivate, and collapse clauses are supported"
+// (worksharing-loop) and "The num_threads, default, private,
+// firstprivate, and shared clauses are supported" (parallel), HPC
+// Compilers User's Guide 25.11 §7.4, 2.9.2 and 2.6. 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, the shape §7.4's parallel entry covers.
+// Expected: "c=1 every b[i] % 100 == 1: yes", exit 0. Each thread's copy
+// of c starts at 1 and grows by 100 per iteration it runs, so b[i] is
+// 1 + 100k (k = iterations its thread ran before i; the schedule is
+// implementation defined, so k is not known); the host's c is unchanged.
+// Observed (2026-10-24, nvc 25.11-0, -O2; this check rerun the same day,
+// separate and managed memory): compile exit status 2,
+// "NVC++-F-0155-Compiler failed to translate OpenMP region (b1.c: 7)".
+// The same with private(c) (c set in the loop) compiles and is correct;
+// nvfortran compiles the Fortran form of the catalog program; gcc
+// (host fallback) prints the expected line.
+// Found by the catalog (omp52/60-c-clause-firstprivate, -lastprivate,
+// -schedule-monotonic: 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: "NVC++-F-0155-Compiler failed to translate OpenMP region", 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
+// Run:   OMP_TARGET_OFFLOAD=mandatory ./a.out
+#include <stdio.h>
+int main(void) {
+  int b[64];
+  int c = 1;
+  #pragma omp target map(from: b) map(tofrom: c)
+  {
+    #pragma omp parallel for default(none) shared(b) firstprivate(c)
+    for (int i = 0; i < 64; i++) {
+      b[i] = c;
+      c = c + 100;
+    }
+  }
+  int ok = (c == 1);
+  for (int i = 0; i < 64; i++)
+    ok = ok && (b[i] % 100 == 1);
+  printf("c=%d every b[i] %% 100 == 1: %s\n", c, ok ? "yes" : "no");
+  return ok ? 0 : 1;
+}
+// site:
+// title: nvc -mp=gpu: "Compiler failed to translate OpenMP region" for firstprivate on a parallel for in a target region
+// control: ../vendor/checks/src/nvhpc/control/nvhpc-c-parallel-for-firstprivate-in-target-control.c private(c) with c set to 1
+// + in each
+// + iteration
+// + instead of firstprivate(c)
+// end site