offtarget 0.1.0__py3-none-any.whl

offload/_root/data/findings/harvest/cce21-internal-procedure-calls-internal-in-target-fault.f90

@@ -0,0 +1,71 @@
+! # Finding: CCE 21 ftn: a target region that calls an internal
+! # function which calls another internal function of the same host faults
+! # on the GPU ("unspecified launch failure"; CCE 19 and 20 correct)
+!
+! - compilers: CCE ftn 21.0.3 and 21.0.4, -O2: this file on MI300A gfx942
+!   (HSA_XNACK 0 and 1; gate confirmed); the libgomp test it comes from also
+!   on MI250X gfx90a with 21.0.3.
+! - expected: r= 43 44 a= 6 7 dev= T
+! - actual: the kernel faults: "HSA_STATUS_ERROR_EXCEPTION: An HSAIL operation
+!   resulted in a hardware exception. code: 0x1016", then "CRAY_ACC_ERROR -
+!   hipStreamSynchronize returned hipErrorLaunchFailure: 'unspecified launch
+!   failure'" at the target construct, exit status 1, every run.
+! - rule: "If a procedure is explicitly or implicitly referenced in a target
+!   construct that does not specify a device clause in which the ancestor
+!   device-modifier appears then that procedure is treated as if its name had
+!   appeared in an enter clause on a declare target directive" (5.2 §13.8
+!   p.285 l.1-3), and a procedure referenced in such a procedure is treated
+!   the same way (5.2 §7.8 p.205 l.3-6). Both rules are in 5.0 (Appendix B:
+!   "implicit declare target directives for some functions ... and
+!   subroutines (Fortran) were added").
+! - regression: CCE 19.0.0 and 20.0.2 are correct on every form (gfx942
+!   both modes; gfx90a).
+! - conditions (one change each, CCE 21.0.3 and 21.0.4, gfx942 X0 and X1):
+!   the fault needs the internal-to-internal call. Correct: wrap does the
+!   addition itself (no call); wrap calls a module procedure instead of the
+!   internal function. Faults (forms of the libgomp test): the target
+!   construct in the main program or in a third internal function; with or
+!   without a module procedure call next to the internal call.
+! - other families: AFAR amdflang correct on this file and on the libgomp
+!   test (gfx942 X0 and X1, gfx90a).
+! - harvest: dev program h2-gomp-f-declare-target-3 (data/bench/harvest2; libgomp
+!   testsuite libgomp.fortran/declare-target-3.f90, GPL-3.0-or-later; this
+!   file is a new program, not a copy), wrong_answer on CCE 21 only, gate
+!   confirmed on gfx90a.
+! - legality: offload.engine.prerun.check accepts it (the rules with the race
+!   rule, and the AFAR flang front end).
+! CCE:  ftn -fopenmp -O2 (module load cce/<v> craype-accel-amd-gfx942 rocm/<r>;
+!       module unload cray-mpich)
+! Run:  OMP_TARGET_OFFLOAD=mandatory ./a.out
+program p
+  use omp_lib
+  implicit none
+  integer :: a(2), r(2)
+  logical :: dev
+  a = [1, 2]
+  dev = .false.
+  !$omp target map(tofrom: a, r) map(from: dev)
+  r = wrap(a)
+  dev = .not. omp_is_initial_device()
+  !$omp end target
+  print '(a,2(1x,i0),a,2(1x,i0),a,l1)', 'r=', r, ' a=', a, ' dev= ', dev
+  if (all(r == [43, 44]) .and. all(a == [6, 7])) then
+    print '(a,i0,a)', 'RESULT ran_on_host=', merge(0, 1, dev), ' check=pass'
+  else
+    print '(a,i0,a)', 'RESULT ran_on_host=', merge(0, 1, dev), ' check=fail'
+  end if
+contains
+  integer function add42(y)
+    integer :: y
+    add42 = y + 42
+  end function
+  function wrap(y)
+    integer :: y(2), wrap(2)
+    y = y + 5
+    wrap(1) = add42(y(1) - 5)
+    wrap(2) = add42(y(2) - 5)
+  end function
+end program p
+! site:
+! title: ftn 21: a target region calling an internal function that calls another internal function faults on the GPU
+! end site

offload/_root/data/findings/harvest/controls/cce-c-implicit-struct-map-partly-present-target-only-control.c

@@ -0,0 +1,22 @@
+// Control of harvest/cce-c-implicit-struct-map-partly-present.c: no target data construct; the members are mapped on the target
+// construct and the structure is implicit there (the OpenMP Examples' Case 3; correct on AFAR, CCE and NVHPC).
+#include <stdio.h>
+#include <stdlib.h>
+#include <omp.h>
+#define N 100
+struct foo { char big[200000]; float a, b; float *p; };
+#pragma omp begin declare target
+void saxpy(struct foo *s) { for (int i = 0; i < N; i++) s->p[i] = s->p[i] * s->a + s->b; }
+#pragma omp end declare target
+int main(void) {
+  struct foo s;
+  int dev = 0;
+  s.a = 2; s.b = 4; s.p = malloc(sizeof(float) * N);
+  for (int i = 0; i < N; i++) s.p[i] = i;
+#pragma omp target map(s.p[:N], s.a, s.b) map(from: dev)
+  { saxpy(&s); dev = !omp_is_initial_device(); }
+  printf("%.0f %.0f dev= %d\n", s.p[0], s.p[N - 1], dev);
+  int ok = s.p[0] == 4 && s.p[N - 1] == 202;
+  printf("RESULT ran_on_host=%d check=%s\n", !dev, ok ? "pass" : "fail");
+  return 0;
+}

offload/_root/data/findings/harvest/controls/cce-c-implicit-struct-map-partly-present-whole-control.c

@@ -0,0 +1,23 @@
+// Control of harvest/cce-c-implicit-struct-map-partly-present.c: s.big added to the target data map, so the whole structure is
+// present when the target region maps it implicitly (correct on AFAR, CCE and NVHPC).
+#include <stdio.h>
+#include <stdlib.h>
+#include <omp.h>
+#define N 100
+struct foo { char big[200000]; float a, b; float *p; };
+#pragma omp begin declare target
+void saxpy(struct foo *s) { for (int i = 0; i < N; i++) s->p[i] = s->p[i] * s->a + s->b; }
+#pragma omp end declare target
+int main(void) {
+  struct foo s;
+  int dev = 0;
+  s.a = 2; s.b = 4; s.p = malloc(sizeof(float) * N);
+  for (int i = 0; i < N; i++) s.p[i] = i;
+#pragma omp target data map(s.big, s.p[:N], s.p, s.a, s.b)
+#pragma omp target map(from: dev)
+  { saxpy(&s); dev = !omp_is_initial_device(); }
+  printf("%.0f %.0f dev= %d\n", s.p[0], s.p[N - 1], dev);
+  int ok = s.p[0] == 4 && s.p[N - 1] == 202;
+  printf("RESULT ran_on_host=%d check=%s\n", !dev, ok ? "pass" : "fail");
+  return 0;
+}

offload/_root/data/findings/harvest/controls/gcc-acc-declare-create-allocatable-control.f90

@@ -0,0 +1,34 @@
+! Control of harvest/gcc-acc-declare-create-allocatable-not-mapped.f90: the same program with an enter data create
+! after the allocate statement (correct on gcc_g90 and gcc_sm80).
+module declare_create_m
+  implicit none
+  integer, allocatable :: a(:)
+  !$acc declare create(a)
+end module declare_create_m
+
+program declare_create_allocatable
+  use openacc, only: acc_device_host, acc_on_device
+  use declare_create_m
+  implicit none
+  integer, parameter :: n = 1000
+  integer :: i, bad, host_flag
+  allocate(a(n))
+  !$acc enter data create(a)
+  a = -1
+  !$acc parallel loop present(a)
+  do i = 1, n
+    a(i) = i
+  end do
+  !$acc update host(a)
+  bad = 0
+  do i = 1, n
+    if (a(i) /= i) bad = bad + 1
+  end do
+  host_flag = 1
+  !$acc parallel num_gangs(1) copy(host_flag)
+  if (.not. acc_on_device(acc_device_host)) host_flag = 0
+  !$acc end parallel
+  print '(a,i0)', 'bad= ', bad
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', bad == 0)
+  deallocate(a)
+end program declare_create_allocatable

offload/_root/data/findings/harvest/controls/gcc-c-same-item-two-maps-control.c

@@ -0,0 +1,17 @@
+// Control of harvest/gcc-c-same-item-two-maps-rejected.c: the variable in one map clause, map(tofrom: x) (compiles;
+// correct on gcc_g90 and gcc_sm80).
+#include <stdio.h>
+#include <omp.h>
+
+int main(void) {
+  int x = 111, host_flag = 1;
+  /* control: the list item in one map clause */
+#pragma omp target map(tofrom: x) map(tofrom: host_flag)
+  {
+    host_flag = omp_is_initial_device();
+    x = x + 1;
+  }
+  printf("x= %d\n", x);
+  printf("RESULT ran_on_host=%d check=%s\n", host_flag, x == 112 ? "pass" : "fail");
+  return 0;
+}

offload/_root/data/findings/harvest/controls/gcc-c-target-data-struct-pointer-section-control.c

@@ -0,0 +1,27 @@
+// Control of harvest/gcc-c-target-data-struct-pointer-section-ice.c: the same three list items with the pointer member listed
+// before its array section (compiles; correct on gcc_g90 and gcc_sm80).
+#include <stdio.h>
+#include <omp.h>
+
+struct S { int a; int *p; };
+
+int main(void) {
+  int v[4] = {1, 2, 3, 4}, host_flag = 1, sum = 0;
+  struct S s;
+  s.a = 10;
+  s.p = v;
+  int *q = v;
+  /* control: the pointer member first, then its array section, then the other member */
+#pragma omp target data map(s.p, s.p[:4], s.a)
+  {
+#pragma omp target map(tofrom: q[:4], host_flag)
+    {
+      host_flag = omp_is_initial_device();
+      for (int i = 0; i < 4; i++) q[i] += 1;
+    }
+  }
+  for (int i = 0; i < 4; i++) sum += v[i];
+  printf("sum= %d\n", sum);
+  printf("RESULT ran_on_host=%d check=%s\n", host_flag, sum == 14 ? "pass" : "fail");
+  return 0;
+}

offload/_root/data/findings/harvest/controls/gcc-c-target-data-two-maps-control.c

@@ -0,0 +1,20 @@
+// Control of harvest/gcc-c-target-data-two-maps-ice.c: the variable in one map clause (compiles; correct on gcc_g90 and
+// gcc_sm80).
+#include <stdio.h>
+#include <omp.h>
+
+int main(void) {
+  int x = 111, host_flag = 1;
+  /* control: the list item in one map clause */
+#pragma omp target data map(from: x)
+  {
+#pragma omp target map(present, alloc: x) map(tofrom: host_flag)
+    {
+      host_flag = omp_is_initial_device();
+      x = 222;
+    }
+  }
+  printf("x= %d\n", x);
+  printf("RESULT ran_on_host=%d check=%s\n", host_flag, x == 222 ? "pass" : "fail");
+  return 0;
+}

offload/_root/data/findings/harvest/controls/gcc-same-item-two-maps-control.f90

@@ -0,0 +1,16 @@
+! Control of harvest/gcc-same-item-two-maps-rejected.f90: the variable in one map clause, map(tofrom: x) (compiles;
+! correct on gcc_g90 and gcc_sm80).
+program map_same_item_once
+  use omp_lib, only: omp_is_initial_device
+  implicit none
+  integer :: x, host_flag
+  x = 111
+  host_flag = 1
+  ! control: the list item in one map clause
+  !$omp target map(tofrom: x) map(tofrom: host_flag)
+    host_flag = merge(1, 0, omp_is_initial_device())
+    x = x + 1
+  !$omp end target
+  print '(a,i0)', 'x= ', x
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', x == 112)
+end program map_same_item_once

offload/_root/data/findings/harvest/controls/gcc-teams-simd-matmul-allocatable-control.f90

@@ -0,0 +1,27 @@
+! Control of harvest/gcc-teams-simd-matmul-allocatable-ice.f90: the product as explicit loops in the same construct
+! (compiles; correct on gcc_g90 and gcc_sm80).
+program matmul_teams_simd
+  use omp_lib, only: omp_is_initial_device
+  implicit none
+  integer :: i, j, k, l, host_flag
+  real, allocatable :: a(:,:,:), b(:,:,:), c(:,:,:)
+  allocate(a(5,7,16), b(7,6,16), c(5,6,16))
+  a = 1.0
+  b = 2.0
+  c = 0.0
+  host_flag = 1
+  !$omp target teams distribute parallel do simd map(tofrom: a, b, c, host_flag)
+  do k = 1, 16
+    if (k == 1) host_flag = merge(1, 0, omp_is_initial_device())
+    do j = 1, 6
+      do i = 1, 5
+        do l = 1, 7
+          c(i,j,k) = c(i,j,k) + a(i,l,k)*b(l,j,k)
+        end do
+      end do
+    end do
+  end do
+  ! every element is 7 * (1.0 * 2.0)
+  print '(a,f8.1)', 'sum= ', sum(c)
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', sum(c) == 5*6*16*14.0)
+end program matmul_teams_simd

offload/_root/data/findings/harvest/gcc-acc-declare-create-allocatable-not-mapped.f90

@@ -0,0 +1,66 @@
+! # Finding (GCC 16.2, known-issues harvest): OpenACC declare create of a module allocatable: the allocate statement
+!   creates no device copy ("is not mapped")
+!
+! - toolchains: gcc_g90 (GCC 16.2.0, AMD Instinct MI250X gfx90a, Tioga) and gcc_sm80 (GCC 16.2.0, NVIDIA A100 sm_80, wingtip);
+!   separate memory only; -O2
+! - build: gfortran -fopenacc -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 -O2 (gcc_sm80)
+! - failure: run_error: is not mapped
+! - observed: `libgomp: [0x...,4000] is not mapped` and exit 1 at the first compute construct that names the array (present(a)), in
+!   every run (gcc_sm80: mandatory exit 5 of 5; unset exit 5 of 5; gcc_g90: mandatory exit 5 of 5; unset exit 5 of 5
+!   (results/parity/<machine>/<tc>/probes.jsonl))
+! - expected: `bad= 0`, then `RESULT ran_on_host=0 check=pass`
+! - rule: in Fortran, for an allocatable in a declare create directive and a non-shared memory device, at an allocate statement
+!   "memory will be allocated in both local memory as well as in the current device memory and the dynamic reference counter will be
+!   set to one" (OpenACC 3.4 §2.13.2 l.3056-3057). The behaviour is OpenACC 2.6's (the changelog of OpenACC 3.4, "Changes from
+!   Version 2.5 to 2.6", margin line 588: "The declare create directive with a Fortran allocatable has new behavior"), the version
+!   GCC documents (libgomp.texi, "Enabling OpenACC": OpenACC 2.6).
+! - same-compiler control (correct, gcc_sm80: mandatory pass 5 of 5; unset pass 5 of 5; gcc_g90: mandatory pass 5 of 5; unset pass 5
+!   of 5 (results/parity/<machine>/<tc>/probes.jsonl)): the same program with `!$acc enter data create(a)` after the allocate
+!   statement (controls/gcc-acc-declare-create-allocatable-control.f90).
+! - other families: CCE 19/20/21 (copy mode, MI300A and MI250X) and NVHPC 25.11/26.9 (separate and managed memory) run the harvested
+!   programs correctly (hk-007, hk-013, hk-087: results/harvest-known/main*). The site's finding matrix runs this file on every
+!   compiler.
+! - harvested programs (6 cells (3 gcc_g90, 3 gcc_sm80); gate: confirmed 6; confirmer: needs_human (R22-expected-weak) 6): hk-007,
+!   hk-013, hk-087
+! - legality: the pre-run check (offload.engine.prerun.check: the rules and AFAR's front end, two witnesses) accepts the harvested
+!   programs; this file is read against the rule above. GCC is a compiler under test only and never a legality witness.
+module declare_create_m
+  implicit none
+  integer, allocatable :: a(:)
+  !$acc declare create(a)
+end module declare_create_m
+
+program declare_create_allocatable
+  use openacc, only: acc_device_host, acc_on_device
+  use declare_create_m
+  implicit none
+  integer, parameter :: n = 1000
+  integer :: i, bad, host_flag
+  allocate(a(n))
+  a = -1
+  !$acc parallel loop present(a)
+  do i = 1, n
+    a(i) = i
+  end do
+  !$acc update host(a)
+  bad = 0
+  do i = 1, n
+    if (a(i) /= i) bad = bad + 1
+  end do
+  host_flag = 1
+  !$acc parallel num_gangs(1) copy(host_flag)
+  if (.not. acc_on_device(acc_device_host)) host_flag = 0
+  !$acc end parallel
+  print '(a,i0)', 'bad= ', bad
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', bad == 0)
+  deallocate(a)
+end program declare_create_allocatable
+! site:
+! title: OpenACC: declare create of a Fortran allocatable gives no device copy at the allocate statement
+! summary: OpenACC 2.6 and later make an allocate statement for an allocatable in a declare create directive allocate the device
+! + copy too. GCC 16.2 does not: the first compute construct that names the array stops with "is not mapped" (exit 1), on the
+! + MI250X and the A100. With an explicit enter data create after the allocate statement the same program runs correctly. CCE and
+! + NVHPC run the harvested programs correctly.
+! control: harvest/controls/gcc-acc-declare-create-allocatable-control.f90 an enter data create after the allocate statement
+! end site

offload/_root/data/findings/harvest/gcc-c-same-item-two-maps-rejected.c

@@ -0,0 +1,45 @@
+// # Finding (GCC 16.2, harvests): the same variable in two map clauses of one target construct is rejected
+//
+// - toolchains: gcc_g90 (GCC 16.2.0, AMD Instinct MI250X gfx90a, Tioga) and gcc_sm80 (GCC 16.2.0, NVIDIA A100 sm_80, wingtip);
+//   separate memory only; -O2
+// - build: gcc -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 -O2 (gcc_sm80)
+// - failure: rejected: error: 'x' appears more than once in map clauses
+// - observed: `error: 'x' appears more than once in map clauses` at the target directive, on both targets
+// - expected: compiles; prints `x= 112` and `RESULT ran_on_host=0 check=pass`
+// - rule: "A list item may appear more than once in the map clauses that are specified on the same directive" (5.2 §5.8.3 p.151
+//   l.14-15).
+// - same-compiler control (compiles; correct, gcc_sm80: mandatory pass 5 of 5; unset pass 5 of 5; gcc_g90: mandatory pass 5 of 5;
+//   unset pass 5 of 5 (results/parity/<machine>/<tc>/probes.jsonl)): the variable in one map clause, map(tofrom: x)
+//   (controls/gcc-c-same-item-two-maps-control.c).
+// - GCC's documentation: no row of libgomp.texi's tables names it (undocumented). GCC's own development testsuite has programs of
+//   this form (libgomp target-map-multi-*, harvested from gcc master 9e5dc385 into harvest2), so later GCC accepts it. On a target
+//   data construct the same form ends in an internal compiler error instead (gcc-c-target-data-two-maps-ice.c).
+// - other families: AFAR, CCE 19/20/21/21.0.4 and NVHPC 25.11/26.9 compile and run this file correctly (site matrix); on the
+//   harvested programs AFAR and CCE are correct, NVHPC fails them another way. The site's finding matrix runs this file on every
+//   compiler.
+// - harvested programs (6 cells (3 gcc_g90, 3 gcc_sm80); gate: confirmed 6; confirmer: compiler_bug (R11-compile-rejection) 6):
+//   h2-gomp-ccc-target-map-multi-1, h2-gomp-ccc-target-map-multi-2, hv-llvm-mapping-map-ordering-tgt-alloc-tofrom
+// - legality: the pre-run check (offload.engine.prerun.check: the rules and AFAR's front end, two witnesses) accepts the harvested
+//   programs. GCC is a compiler under test only and never a legality witness.
+#include <stdio.h>
+#include <omp.h>
+
+int main(void) {
+  int x = 111, host_flag = 1;
+  /* the same list item in two map clauses of one construct */
+#pragma omp target map(alloc: x) map(tofrom: x) map(tofrom: host_flag)
+  {
+    host_flag = omp_is_initial_device();
+    x = x + 1;
+  }
+  printf("x= %d\n", x);
+  printf("RESULT ran_on_host=%d check=%s\n", host_flag, x == 112 ? "pass" : "fail");
+  return 0;
+}
+// site:
+// title: The same variable in two map clauses of one target construct is rejected
+// summary: OpenMP 5.2 allows a list item in more than one map clause of one directive. GCC 16.2 rejects a target construct
+// + with map(alloc: x) map(tofrom: x) for both offload targets; its documentation does not list the gap.
+// control: harvest/controls/gcc-c-same-item-two-maps-control.c the variable in one map clause, map(tofrom: x)
+// end site

offload/_root/data/findings/harvest/gcc-c-strided-section-rejected.c

@@ -0,0 +1,70 @@
+// # Finding (GCC 16.2, LLVM/AOMP harvest): C array sections with a stride are rejected ("expected ']' before ':' token")
+//
+// - toolchains: gcc_g90 (GCC 16.2.0, AMD Instinct MI250X gfx90a, Tioga) and gcc_sm80 (GCC 16.2.0, NVIDIA A100 sm_80, wingtip);
+//   separate memory only; -O2
+// - build: gcc -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 -O2 (gcc_sm80)
+// - failure: rejected: expected ']' before ':' token
+// - observed: `error: expected ']' before ':' token` at the stride of `a[0:8:2]` in the target update directive, on both targets
+// - expected: compiles; prints `bad= 0` and `RESULT ran_on_host=0 check=pass` (only the even elements come back)
+// - rule: in C, an array section is written `[ lower-bound : length : stride]` (5.2 §3.2.5 p.64 l.3-5; the stride form is OpenMP
+//   5.0's).
+// - GCC's documentation: libgomp.texi, OpenMP 5.0 table: "Array sections with non-unit strides in C and C++: N" (not supported,
+//   documented).
+// - other families: AFAR runs the harvested programs correctly (copy mode, MI300A and MI250X); CCE 19/20/21 and NVHPC fail them
+//   (cce-c-strided-target-update.c: CCE behaves incorrectly; NVHPC rejects). The site's finding matrix runs this file on every
+//   compiler: AFAR runs it correctly in copy mode and prints `bad= 8` in unified mode (HSA_XNACK=1), which this file's check
+//   does not allow but the specification does ("The corresponding variable in the device data environment may share storage with
+//   the original variable. Writes to the corresponding variable may alter the value of the original variable", 5.2 §1.4.2 p.28
+//   l.12-13): the odd elements change too. The check holds for separate memory only, the memory GCC has.
+// - harvested programs (50 cells (25 gcc_g90, 25 gcc_sm80); gate: confirmed 50; confirmer: compiler_bug (R11-compile-rejection) 28,
+//   needs_human (R12b-compile-undecided) 22): hv-llvm-offloading-strided-update-strided-update-count-expression,
+//   hv-llvm-offloading-strided-update-strided-update-from, hv-llvm-offloading-strided-update-strided-update-from-pointer,
+//   hv-llvm-offloading-strided-update-strided-update-multidim-offset,
+//   hv-llvm-offloading-strided-update-strided-update-multiple-arrays-variable-stride,
+//   hv-llvm-offloading-strided-update-strided-update-multiple-from, hv-llvm-offloading-strided-update-strided-update-multiple-to,
+//   hv-llvm-offloading-strided-update-strided-update-partial-from,
+//   hv-llvm-offloading-strided-update-strided-update-ptr-multiple-from,
+//   hv-llvm-offloading-strided-update-strided-update-ptr-multiple-to,
+//   hv-llvm-offloading-strided-update-strided-update-ptr-partial-from,
+//   hv-llvm-offloading-strided-update-strided-update-ptr-partial-to,
+//   hv-llvm-offloading-strided-update-strided-update-ptr-variable-count-and-stride,
+//   hv-llvm-offloading-strided-update-strided-update-ptr-variable-stride,
+//   hv-llvm-offloading-strided-update-strided-update-struct-count-expression,
+//   hv-llvm-offloading-strided-update-strided-update-struct-from,
+//   hv-llvm-offloading-strided-update-strided-update-struct-multiple-from,
+//   hv-llvm-offloading-strided-update-strided-update-struct-multiple-to,
+//   hv-llvm-offloading-strided-update-strided-update-struct-partial-from,
+//   hv-llvm-offloading-strided-update-strided-update-struct-partial-to, hv-llvm-offloading-strided-update-strided-update-struct-to,
+//   hv-llvm-offloading-strided-update-strided-update-struct-variable-stride, hv-llvm-offloading-strided-update-strided-update-to,
+//   hv-llvm-offloading-strided-update-strided-update-to-pointer,
+//   hv-llvm-offloading-strided-update-strided-update-variable-stride-misc
+// - legality: the pre-run check (offload.engine.prerun.check: the rules and AFAR's front end, two witnesses) accepts the harvested
+//   programs. GCC is a compiler under test only and never a legality witness.
+#include <stdio.h>
+#include <omp.h>
+
+int main(void) {
+  int a[16], host_flag = 1, bad = 0;
+  for (int i = 0; i < 16; i++) a[i] = -1;
+#pragma omp target enter data map(to: a)
+#pragma omp target map(tofrom: host_flag)
+  {
+    host_flag = omp_is_initial_device();
+    for (int i = 0; i < 16; i++) a[i] = i;
+  }
+  /* every second element of the first 16: a[0], a[2], ..., a[14] */
+#pragma omp target update from(a[0:8:2])
+  for (int i = 0; i < 16; i++) bad += (i % 2 == 0) ? (a[i] != i) : (a[i] != -1);
+#pragma omp target exit data map(delete: a)
+  printf("bad= %d\n", bad);
+  printf("RESULT ran_on_host=%d check=%s\n", host_flag, bad ? "fail" : "pass");
+  return 0;
+}
+// site:
+// title: C array sections with a stride ([lower-bound:length:stride]) are rejected
+// summary: OpenMP 5.0 added a stride to C array sections. GCC 16.2 rejects a strided section in a target update from clause
+// + ("expected ']' before ':' token") for both offload targets; GCC's documentation lists non-unit strides in C and C++ as not
+// + supported. AFAR runs the harvested programs correctly (and this file in copy mode; the file's check assumes separate
+// + memory).
+// end site

offload/_root/data/findings/harvest/gcc-c-target-data-struct-pointer-section-ice.c

@@ -0,0 +1,78 @@
+// # Finding (GCC 16.2, OpenMP Examples harvest): members of one structure in a target data construct, the pointer member as an
+//   array section before itself: internal compiler error (segmentation fault) in the gimplifier
+//
+// - toolchains: gcc_g90 (GCC 16.2.0, AMD Instinct MI250X gfx90a, Tioga) and gcc_sm80 (GCC 16.2.0, NVIDIA A100 sm_80, wingtip);
+//   separate memory only; -O2
+// - build: gcc -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 -O2 (gcc_sm80)
+// - failure: ice: internal compiler error: Segmentation fault
+// - observed: `internal compiler error: Segmentation fault` at the target data directive, on both targets; the host compiler stops
+//   before any offload code is made (the same with -foffload=disable and at -O0). A debugger shows the fault in
+//   omp_gather_mapping_groups_1 (gimplify.cc:11160), called from gimplify_adjust_omp_clauses for the target data construct.
+// - expected: compiles; prints `sum= 14` and `RESULT ran_on_host=0 check=pass`
+// - rule: "All map clause list items that have the same containing structure or share storage result in a single mappable
+//   storage block that contains the storage of the list items" (5.2 §5.8.3 p.152 l.29-31): s.p[:4], s.p and s.a are map clause
+//   list items of one structure, and nothing in 5.2 limits the order of the list items of one map clause list. The OpenMP
+//   Examples (target_struct_map.4, Case 1) write the form `map(S1.p[:N],S1.p,S1.a,S1.b)` and document that it works.
+// - trigger (hand-reduced from the Examples program; compile-only probes on gcc_sm80, 2026-11-01): the construct maps two or more
+//   members of one structure and the member with the highest offset is a pointer that is listed both as an array section and by
+//   itself, the section first. Reordering the list is the only change in the control: `map(s.p, s.p[:4], s.a)` compiles, as do
+//   `map(s.p[:4], s.a, s.p)` and `map(s.a, s.p[:4], s.p)`. The pointer member alone (`map(s.p[:4], s.p)`) compiles, and so does
+//   the list with a mapped member of higher offset than the pointer (`struct S { int a; int *p; int b; }` with
+//   `map(s.p[:4], s.p, s.b)`); the fault needs the pointer to be the last mapped member. It also occurs on `target` and
+//   `target enter data` with the same list, and with a second pointer member in the place of `a`. The repeat `map(s.p[:4], s.p,
+//   s.p, s.a)` stops with an internal compiler error in omp_group_base (gimplify.cc:11337). The program of
+//   harvest/cce-c-implicit-struct-map-partly-present.c (`map(s.p[:N], s.p, s.a, s.b)`, the pointer last in the structure) stops
+//   with the same error on both targets (site matrix rows, 2026-11-01).
+// - gate (this file, 2026-11-01): the internal compiler error in all four environments on both targets: gcc_sm80 a, b and d on
+//   wingtip GPU 0 (b in a build directory named in upper-case letters only), c on GPU 1; gcc_g90 a, b and d on
+//   tioga39, c on tioga38 (results/triage2/wingtip/gcc_sm80/gate.jsonl, results/triage2/tioga/gcc_g90/gate.jsonl).
+// - same-compiler control (compiles; correct, in each of the four environments on gcc_sm80 and gcc_g90: mandatory pass 5 of 5;
+//   unset pass 5 of 5): the same three list items with the pointer member first, map(s.p, s.p[:4], s.a)
+//   (controls/gcc-c-target-data-struct-pointer-section-control.c).
+// - not the defect of gcc-c-target-data-two-maps-ice.c: that one repeats a scalar in two map clauses and stops in
+//   install_var_field (omplower); this one needs the structure members and stops earlier, in the gimplifier.
+// - other families: AFAR (amdclang) and CCE 19/20/21/21.0.4 compile and run this file and the control correctly (MI300A, HSA_XNACK
+//   0 and 1; results/triage2/other3.jsonl); NVHPC 25.11 and 26.9 run this file correctly in separate and managed memory and stop
+//   on the control with `variable in data clause is partially present on the device: name=s.p[:4]`
+//   (results/triage2/wingtip/nvhpc/nv2.a.jsonl). The site's finding matrix runs this file on every compiler.
+// - harvested program (2 cells (1 gcc_g90, 1 gcc_sm80); gate: gcc_g90 confirmed, gcc_sm80 reproduced in a, b, c and d (the gate
+//   field of its confirmer row is unset); confirmer: compiler_bug (R10-compile-ice) 2): h2-ompex-target-struct-map-4-c
+//   (data/bench/harvest2; OpenMP Examples target_struct_map.4.c, whose Case 1 is the trigger). CCE and NVHPC fail the same program
+//   another way (harvest/cce-c-implicit-struct-map-partly-present.c).
+// - legality: offload.engine.prerun.check (the rules with the race rule, and the AFAR clang front end: two witnesses) accepts this
+//   file and the control (2026-11-01, Tuolumne pbatch; results/triage2/legal2.json), and accepts the harvested program
+//   (results/harvest2/rules.jsonl, prerun.part.*.jsonl). GCC is a compiler under test only and never a legality witness.
+#include <stdio.h>
+#include <omp.h>
+
+struct S { int a; int *p; };
+
+int main(void) {
+  int v[4] = {1, 2, 3, 4}, host_flag = 1, sum = 0;
+  struct S s;
+  s.a = 10;
+  s.p = v;
+  int *q = v;
+  /* the pointer member as an array section and by itself, then another member of the same structure */
+#pragma omp target data map(s.p[:4], s.p, s.a)
+  {
+#pragma omp target map(tofrom: q[:4], host_flag)
+    {
+      host_flag = omp_is_initial_device();
+      for (int i = 0; i < 4; i++) q[i] += 1;
+    }
+  }
+  for (int i = 0; i < 4; i++) sum += v[i];
+  printf("sum= %d\n", sum);
+  printf("RESULT ran_on_host=%d check=%s\n", host_flag, sum == 14 ? "pass" : "fail");
+  return 0;
+}
+// site:
+// title: Members of one structure in a target data construct: internal compiler error
+// summary: OpenMP 5.2 allows a pointer member to be listed as an array section and by itself, next to another member of the same
+// + structure (the OpenMP Examples show it). GCC 16.2 stops with an internal compiler error (segmentation fault in the
+// + gimplifier) on a target data construct with map(s.p[:4], s.p, s.a), for both offload targets. With the pointer member
+// + listed first, map(s.p, s.p[:4], s.a), the same program compiles and runs correctly.
+// control: harvest/controls/gcc-c-target-data-struct-pointer-section-control.c the pointer member listed before its array section
+// end site

offload/_root/data/findings/harvest/gcc-c-target-data-two-maps-ice.c

@@ -0,0 +1,49 @@
+// # Finding (GCC 16.2, LLVM/AOMP harvest): the same variable in two map clauses of a target data construct: internal compiler
+//   error in install_var_field
+//
+// - toolchains: gcc_g90 (GCC 16.2.0, AMD Instinct MI250X gfx90a, Tioga) and gcc_sm80 (GCC 16.2.0, NVIDIA A100 sm_80, wingtip);
+//   separate memory only; -O2
+// - build: gcc -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 -O2 (gcc_sm80)
+// - failure: ice: internal compiler error: in install_var_field
+// - observed: `internal compiler error: in install_var_field, at omp-low.cc:806` ("during GIMPLE pass: omplower") at the target
+//   data directive, on both targets (the host compiler fails before any offload code is made)
+// - expected: compiles; prints `x= 222` and `RESULT ran_on_host=0 check=pass`
+// - rule: "A list item may appear more than once in the map clauses that are specified on the same directive" (5.2 §5.8.3 p.151
+//   l.14-15).
+// - same-compiler control (compiles; correct, gcc_sm80: mandatory pass 5 of 5; unset pass 5 of 5; gcc_g90: mandatory pass 5 of 5;
+//   unset pass 5 of 5 (results/parity/<machine>/<tc>/probes.jsonl)): the variable in one map clause, map(from: x)
+//   (controls/gcc-c-target-data-two-maps-control.c).
+// - other families: AFAR runs the harvested programs correctly (copy mode, MI300A and MI250X); CCE 19/20/21 and NVHPC 25.11/26.9
+//   fail them differently (results/harvest/main). The site's finding matrix runs this file on every compiler.
+// - harvested programs (8 cells (4 gcc_g90, 4 gcc_sm80); gate: confirmed 8; confirmer: compiler_bug (R10-compile-ice)
+//   8): h2-gomp-ccc-target-map-multi-4, hv-llvm-mapping-map-ordering-tgt-data-alloc-from,
+//   hv-llvm-mapping-map-ordering-tgt-data-alloc-to-from, hv-llvm-mapping-map-ordering-tgt-exit-data-delete-from
+// - legality: the pre-run check (offload.engine.prerun.check: the rules and AFAR's front end, two witnesses) accepts the harvested
+//   programs; this file is read against the rule above. GCC is a compiler under test only and never a legality witness.
+#include <stdio.h>
+#include <omp.h>
+
+int main(void) {
+  int x = 111, host_flag = 1;
+  /* the same list item in two map clauses of one target data construct */
+#pragma omp target data map(alloc: x) map(from: x)
+  {
+#pragma omp target map(present, alloc: x) map(tofrom: host_flag)
+    {
+      host_flag = omp_is_initial_device();
+      x = 222;
+    }
+  }
+  printf("x= %d\n", x);
+  printf("RESULT ran_on_host=%d check=%s\n", host_flag, x == 222 ? "pass" : "fail");
+  return 0;
+}
+// site:
+// title: The same variable in two map clauses of a target data construct: internal compiler error
+// summary: OpenMP 5.2 allows a list item in more than one map clause of one directive. GCC 16.2 stops with an internal compiler
+// + error (install_var_field, omplower) on a target data construct with map(alloc: x) map(from: x), for both offload targets.
+// + With the variable in one map clause the same program compiles and runs correctly. AFAR runs the harvested programs
+// + correctly.
+// control: harvest/controls/gcc-c-target-data-two-maps-control.c the variable in one map clause, map(from: x)
+// end site

offload/_root/data/findings/harvest/gcc-same-item-two-maps-rejected.f90

@@ -0,0 +1,46 @@
+! # Finding (GCC 16.2, harvests): the same variable in two map clauses of one target construct is rejected
+!
+! - toolchains: gcc_g90 (GCC 16.2.0, AMD Instinct MI250X gfx90a, Tioga) and gcc_sm80 (GCC 16.2.0, NVIDIA A100 sm_80, wingtip);
+!   separate memory only; -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 -O2 (gcc_sm80)
+! - failure: rejected: Error: Symbol 'x' present on multiple clauses at (1)
+! - observed: `Error: Symbol 'x' present on multiple clauses at (1)` at the target directive, on both targets
+! - expected: compiles; prints `x= 112` and `RESULT ran_on_host=0 check=pass`
+! - rule: "A list item may appear more than once in the map clauses that are specified on the same directive" (5.2 §5.8.3 p.151
+!   l.14-15).
+! - same-compiler control (compiles; correct, gcc_sm80: mandatory pass 5 of 5; unset pass 5 of 5; gcc_g90: mandatory pass 5 of 5;
+!   unset pass 5 of 5 (results/parity/<machine>/<tc>/probes.jsonl)): the variable in one map clause, map(tofrom: x)
+!   (controls/gcc-same-item-two-maps-control.f90).
+! - GCC's documentation: no row of libgomp.texi's tables names it (undocumented). GCC's own development testsuite has programs of
+!   this form (libgomp target-map-multi-*, harvested from gcc master 9e5dc385 into harvest2), so later GCC accepts it. On a target
+!   data construct the same form ends in an internal compiler error instead (gcc-c-target-data-two-maps-ice.c).
+! - other families: AFAR, CCE 19/20/21/21.0.4 and NVHPC 25.11/26.9 compile and run this file correctly (site matrix); on the
+!   harvested programs AFAR and CCE are correct, NVHPC fails them another way. The site's finding matrix runs this file on every
+!   compiler.
+! - harvested programs (8 cells (5 gcc_g90, 3 gcc_sm80); gate: confirmed 8; confirmer: compiler_bug (R11-compile-rejection) 6, gate
+!   only 2): h2-gomp-f-target-map-multi-1, h2-gomp-f-target-map-multi-4, h2-gomp-f-target-map-multi-5, sections-omp-1024-1,
+!   sections-omp-64-1
+! - legality: the pre-run check (offload.engine.prerun.check: the rules and AFAR's front end, two witnesses) accepts the harvested
+!   programs. GCC is a compiler under test only and never a legality witness.
+program map_same_item_twice
+  use omp_lib, only: omp_is_initial_device
+  implicit none
+  integer :: x, host_flag
+  x = 111
+  host_flag = 1
+  ! the same list item in two map clauses of one construct
+  !$omp target map(alloc: x) map(tofrom: x) map(tofrom: host_flag)
+    host_flag = merge(1, 0, omp_is_initial_device())
+    x = x + 1
+  !$omp end target
+  print '(a,i0)', 'x= ', x
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', x == 112)
+end program map_same_item_twice
+! site:
+! title: The same variable in two map clauses of one target construct is rejected
+! summary: OpenMP 5.2 allows a list item in more than one map clause of one directive. GCC 16.2 rejects a target construct
+! + with map(alloc: x) map(tofrom: x) for both offload targets; its documentation does not list the gap.
+! same_as: harvest/gcc-c-same-item-two-maps-rejected
+! control: harvest/controls/gcc-same-item-two-maps-control.f90 the variable in one map clause, map(tofrom: x)
+! end site