offtarget 0.1.0__py3-none-any.whl

offload/_root/data/findings/gcc/controls/gcc-target-in-task-control.c

@@ -0,0 +1,26 @@
+#include <stdio.h>
+#include <omp.h>
+
+enum { n = 64 };
+
+int main(void) {
+  int a[n], b[n];
+  int host_flag = 1, bad = 0;
+  for (int i = 0; i < n; i++) {
+    a[i] = i + 1;
+    b[i] = 0;
+  }
+  {
+    #pragma omp target map(to: a) map(from: b) map(tofrom: host_flag)
+    {
+      host_flag = omp_is_initial_device();
+      for (int i = 0; i < n; i++)
+        b[i] = 2 * a[i] + 1;
+    }
+  }
+  for (int i = 0; i < n; i++)
+    bad += b[i] != 2 * (i + 1) + 1;
+  printf("bad= %d\n", bad);
+  printf("RESULT ran_on_host=%d check=%s\n", host_flag, bad == 0 ? "pass" : "fail");
+  return 0;
+}

offload/_root/data/findings/gcc/controls/gcc-target-in-task-control.f90

@@ -0,0 +1,21 @@
+program target_no_task
+  use omp_lib, only: omp_is_initial_device
+  implicit none
+  integer, parameter :: n = 64
+  integer :: a(n), b(n)
+  integer :: i, host_flag, bad
+  do i = 1, n
+    a(i) = i
+    b(i) = 0
+  end do
+  host_flag = 1
+    !$omp target map(to: a) map(from: b) map(tofrom: host_flag)
+      host_flag = merge(1, 0, omp_is_initial_device())
+      do i = 1, n
+        b(i) = 2*a(i) + 1
+      end do
+    !$omp end target
+  bad = count(b /= 2*[(i, i = 1, n)] + 1)
+  print '(a,i0)', 'bad= ', bad
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', bad == 0)
+end program target_no_task

offload/_root/data/findings/gcc/gcc-acc-bind-device-type-rejected.f90

@@ -0,0 +1,71 @@
+! # Finding (GCC 16.2): OpenACC device_type and routine bind clauses are rejected (Fortran); the reproducer is the catalog program
+!   acc34-clause-device_type
+!
+! - 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; OMP_TARGET_OFFLOAD=mandatory
+! - 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: rejected
+! - observed: `Error: Failed to match clause at (1)` at device_type(*) (and at the bind clause of acc34-clause-bind), on both GPUs.
+!   acc34-clause-bind also reports `Invalid NAME 'host_val' in !$ACC ROUTINE (NAME )` at `!$acc routine(host_val) seq
+!   bind(dev_val)`: the named form of the routine directive names a procedure gfortran does not accept there (an external
+!   procedure); it is the same program's second rejection, not studied separately.
+! - expected: compiles; `RESULT ran_on_host=0 check=pass`
+! - spec: the device_type clause (OpenACC 3.4 §2.4 l.1013-1015) and the routine directive's bind clause (§2.15.1 l.3405-3407: "The
+!   bind clause specifies the name to use when calling the procedure on a device other than the host"); both are OpenACC 2.0
+!   clauses.
+! - GCC 16.2 documentation (libgomp.texi "Enabling OpenACC"): "A complete description of all OpenACC directives accepted may be
+!   found in the OpenACC Application Programming Interface manual, version 2.6"; _OPENACC is 201711 (2.6). No list of OpenACC gaps
+!   is documented.
+! - other families: CCE 19/20/21 (MI300A, MI250X) and NVHPC 25.11/26.9 compile and run both programs correctly.
+! - gate and confirmer: 4 cells (2 gcc_g90, 2 gcc_sm80), each confirmed in the gate's four environments (a-d;
+!   results/gcc/gate-tioga/ and gate-wingtip/ verdicts.jsonl); confirmer verdicts (results/gcc/confirm/batch.gcc_*.jsonl):
+!   compiler_bug (R11-compile-rejection) 4
+! - catalog programs (2): acc34-clause-bind, acc34-clause-device_type
+! - legality: the catalog programs are legal by construction (offload.engine.gen, c_gen and acc_gen
+!   check every program against the catalog rules and the offload scope as it is built; no
+!   compiler). GCC is a compiler under test only: never a legality witness, here or for another
+!   family's case (catalog/machines.yaml under_test_only).
+! Generated by compliance.gen (OpenACC 3.4, free-form Fortran). Do not edit.
+! id: acc34-clause-device_type
+! primary atom: acc.clause.device_type
+! legal: yes
+! observable: yes
+! ran_on_host: inside the compute region of interest (acc_on_device)
+! evidence: implementation_defined
+! needs: none
+! std: f2008
+! no oracle (implementation_defined): the device types and their names are implementation-defined; the clauses after device_type(*)
+! are hints here (vector_length)
+! basis: OpenACC 3.4 §2.4, p.32: "The supported device types are implementation-defined."
+program gen_prog
+  use openacc, only: acc_device_host, acc_on_device
+  implicit none
+  integer, parameter :: n = 64
+  integer, allocatable, target :: a(:), b(:)
+  integer :: ref(n)
+  integer :: i, host_flag
+  logical :: ok
+  allocate(a(n), b(n))
+  do i = 1, n
+    a(i) = i
+    b(i) = 0
+    ref(i) = 2*i + 1
+  end do
+  host_flag = 1
+  !$acc parallel loop copyin(a) copyout(b) copy(host_flag) device_type(*) vector_length(32)
+  do i = 1, n
+    if (i == 1) host_flag = merge(1, 0, acc_on_device(acc_device_host))
+    b(i) = 2*a(i) + 1
+  end do
+  ok = all(b == ref)
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', ok)
+  deallocate(a, b)
+end program gen_prog
+! site:
+! title: OpenACC device_type clause and routine bind clause are rejected ("Failed to match clause")
+! summary: GCC 16.2 rejects the OpenACC device_type clause (here device_type(*) vector_length(32) on a parallel loop) and the bind
+! + clause of the routine directive, in Fortran ("Failed to match clause") and C ("expected an OpenACC clause before '(' token").
+! + Both are OpenACC 2.0 clauses, and GCC documents OpenACC 2.6. CCE and NVHPC compile and run the Fortran programs, NVHPC the C
+! + programs.
+! end site

offload/_root/data/findings/gcc/gcc-acc-c-bind-device-type-rejected.c

@@ -0,0 +1,76 @@
+// # Finding (GCC 16.2): OpenACC device_type and routine bind clauses are rejected (C); the reproducer is the catalog program
+//   acc34-c-clause-device_type
+//
+// - 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; OMP_TARGET_OFFLOAD=mandatory
+// - build: gcc -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: rejected: expected an OpenACC clause before
+// - observed: `error: expected an OpenACC clause before '(' token` on both GPUs.
+// - expected: compiles; `RESULT ran_on_host=0 check=pass`
+// - spec: the device_type clause (OpenACC 3.4 §2.4 l.1013-1015) and the routine directive's bind clause (§2.15.1 l.3405-3407: "The
+//   bind clause specifies the name to use when calling the procedure on a device other than the host"); both are OpenACC 2.0
+//   clauses.
+// - GCC 16.2 documentation (libgomp.texi "Enabling OpenACC"): "A complete description of all OpenACC directives accepted may be
+//   found in the OpenACC Application Programming Interface manual, version 2.6"; _OPENACC is 201711 (2.6). No list of OpenACC gaps
+//   is documented.
+// - other families: NVHPC 25.11/26.9 compile and run both programs correctly (CCE has no OpenACC C).
+// - gate and confirmer: 4 cells (2 gcc_g90, 2 gcc_sm80), each confirmed in the gate's four environments (a-d;
+//   results/gcc/gate-tioga/ and gate-wingtip/ verdicts.jsonl); confirmer verdicts (results/gcc/confirm/batch.gcc_*.jsonl):
+//   compiler_bug (R11-compile-rejection) 4
+// - catalog programs (2): acc34-c-clause-bind, acc34-c-clause-device_type
+// - legality: the catalog programs are legal by construction (offload.engine.gen, c_gen and acc_gen
+//   check every program against the catalog rules and the offload scope as it is built; no
+//   compiler). GCC is a compiler under test only: never a legality witness, here or for another
+//   family's case (catalog/machines.yaml under_test_only).
+// Generated by compliance.acc_c_gen (OpenACC 3.4, C11): the C port (offload.engine.f2c) of acc34-clause-device_type. Do not edit.
+// id: acc34-c-clause-device_type
+// primary atom: acc.clause.device_type
+// legal: yes
+// observable: yes
+// ran_on_host: inside the compute region of interest (acc_on_device)
+// evidence: implementation_defined
+// needs: none
+// std: c11
+// no oracle (implementation_defined): the device types and their names are implementation-defined; the clauses after device_type(*)
+// are hints here (vector_length)
+// basis: OpenACC 3.4 §2.4, p.32: "The supported device types are implementation-defined."
+#include <stdio.h>
+#include <stdbool.h>
+#include <openacc.h>
+
+enum { n = 64 };
+
+int main(void) {
+  int a[n];
+  int b[n];
+  int ref[n];
+  int host_flag;
+  bool ok;
+  for (int i = 1; i <= n; i++) {
+    a[i - 1] = i;
+    b[i - 1] = 0;
+    ref[i - 1] = 2 * i + 1;
+  }
+  host_flag = 1;
+  #pragma acc parallel loop copyin(a) copyout(b) copy(host_flag) device_type(*) \
+      vector_length(32)
+  for (int i = 1; i <= n; i++) {
+    if (i == 1) host_flag = (acc_on_device(acc_device_host) ? 1 : 0);
+    b[i - 1] = 2 * a[i - 1] + 1;
+  }
+  bool t1_ = true;
+  for (int k2_ = 0; k2_ < n; k2_++)
+    t1_ = t1_ && (b[k2_] == ref[k2_]);
+  ok = t1_;
+  printf("RESULT ran_on_host=%d check=%s\n", host_flag, ok ? "pass" : "fail");
+  return 0;
+}
+// site:
+// title: OpenACC device_type clause and routine bind clause are rejected (C)
+// summary: GCC 16.2 rejects the OpenACC device_type clause (here device_type(*) vector_length(32) on a parallel loop) and the bind
+// + clause of the routine directive, in Fortran ("Failed to match clause") and C ("expected an OpenACC clause before '(' token").
+// + Both are OpenACC 2.0 clauses, and GCC documents OpenACC 2.6. CCE and NVHPC compile and run the Fortran programs, NVHPC the C
+// + programs.
+// same_as: gcc/gcc-acc-bind-device-type-rejected
+// end site

offload/_root/data/findings/gcc/gcc-acc-c-detach-delete-attach-underflow.c

@@ -0,0 +1,74 @@
+// # Finding (GCC 16.2): the C form of gcc-acc-detach-delete-attach-underflow.f90
+//
+// - 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; OMP_TARGET_OFFLOAD=mandatory
+// - build: gcc -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: attach count underflow
+// - observed: `libgomp: attach count underflow` and exit 1 at the exit data delete, in every run on both GPUs (this file: gcc_sm80
+//   and gcc_g90, 5 of 5 each with OMP_TARGET_OFFLOAD mandatory and 5 of 5 unset; results/gcc/<tc>/probes-findings.jsonl); the
+//   parallel loop before it ran on the device.
+// - expected: `sum= 2144`, then `RESULT ran_on_host=0 check=pass`
+// - rule: in OpenACC 2.6, the version GCC documents, the delete clause performs a detach action, and "If the current device is a
+//   shared memory device, or if var is not present on the device, or if the attachment counter for var for the pointer is zero, no
+//   action is taken. Otherwise, the attachment counter for the pointer var is decremented" (OpenACC 2.6, section 2.7.2 "Detach
+//   Action", margin lines 1115-1122; the same sentence in OpenACC 3.0, 3.2 and 3.3, the last at margin lines 1710-1711). After exit
+//   data detach the attachment counter is zero, so the delete leaves it alone. OpenACC 3.4 rewords the actions with the same
+//   intent: the delete clause performs a decrement counter action on the attachment counter (OpenACC 3.4 §2.7.12 l.2022-2025), "If
+//   the reference counter is already zero, its value is left unchanged" (§2.7.2 l.1733-1735), and a detach pointer action at a zero
+//   counter is defined (§2.7.2 l.1794-1796); the data clause errors (§2.7.3) name no attachment-counter error.
+// - same-compiler control (correct: `sum= 2144`, 5 of 5 runs on each GPU): the same program without the exit data detach
+//   (controls/gcc-acc{,-c}-detach-control.{f90,c}).
+// - other families: CCE 19/20/21 (Fortran, MI300A and MI250X) and NVHPC 25.11/26.9 (both languages, separate and managed memory)
+//   run the catalog programs acc34-clause-detach and acc34-c-clause-detach to the end (their check cannot see the detach:
+//   unobservable). The site's finding matrix runs this file on every compiler.
+// - gate and confirmer: 2 cells (1 gcc_g90, 1 gcc_sm80), each confirmed in the gate's four environments (a-d;
+//   results/gcc/gate-tioga/ and gate-wingtip/ verdicts.jsonl); confirmer verdicts (results/gcc/confirm/batch.gcc_*.jsonl):
+//   needs_human (R22-expected-weak) 2
+// - catalog programs (1): acc34-c-clause-detach
+// - legality: read against the spec (the rule above); the catalog programs of the list are legal by construction (offload.engine.gen,
+//   c_gen and acc_gen; no compiler). GCC is a compiler under test only and never a legality witness.
+#include <stdio.h>
+#include <stdlib.h>
+#include <openacc.h>
+
+enum { n = 64 };
+struct holder {
+  int *v;
+};
+
+int main(void) {
+  int b[n];
+  int host_flag = 1, sum = 0;
+  struct holder h;
+  h.v = malloc(n * sizeof(int));
+  for (int i = 0; i < n; i++) {
+    h.v[i] = 1;
+    b[i] = 0;
+  }
+  #pragma acc enter data copyin(h)
+  #pragma acc enter data copyin(h.v[0:n])
+  #pragma acc parallel loop copyout(b) copy(host_flag) present(h)
+  for (int i = 0; i < n; i++) {
+    if (i == 0) host_flag = acc_on_device(acc_device_host) ? 1 : 0;
+    b[i] = i + 1 + h.v[i];
+  }
+  #pragma acc exit data detach(h.v)
+  #pragma acc exit data delete(h.v[0:n])
+  #pragma acc exit data delete(h)
+  for (int i = 0; i < n; i++)
+    sum += b[i];
+  free(h.v);
+  printf("sum= %d\n", sum);
+  printf("RESULT ran_on_host=%d check=%s\n", host_flag, sum == 2144 ? "pass" : "fail");
+  return 0;
+}
+// site:
+// title: OpenACC: exit data delete after exit data detach stops with "attach count underflow" (C)
+// summary: After exit data detach of an attached member pointer, exit data delete of its target should leave the attachment counter
+// + at zero and free the data. GCC 16.2's libgomp stops the program instead with "attach count underflow" (exit 1), in Fortran and
+// + C, on the MI250X and the A100; without the detach the same program runs correctly. OpenACC 2.6, the version GCC documents, says
+// + a detach action at a zero attachment counter takes no action.
+// control: gcc/controls/gcc-acc-c-detach-control.c the same program without the exit data detach
+// same_as: gcc/gcc-acc-detach-delete-attach-underflow
+// end site

offload/_root/data/findings/gcc/gcc-acc-c-gang-dim-rejected.c

@@ -0,0 +1,79 @@
+// # Finding (GCC 16.2): the OpenACC 3.3 gang(dim:) argument is rejected (C); the reproducer is the catalog program
+//   acc34-c-clause-gang-dim
+//
+// - 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; OMP_TARGET_OFFLOAD=mandatory
+// - build: gcc -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: rejected
+// - observed: `error: 'dim' undeclared (first use in this function)` on both GPUs.
+// - expected: compiles; `RESULT ran_on_host=0 check=pass`
+// - spec: the dim argument of gang (OpenACC 3.4 §2.9.2 l.2371; added in 3.3, "Changes from Version 3.2 to 3.3", margin line 800).
+// - GCC 16.2 documentation (libgomp.texi "Enabling OpenACC"): "A complete description of all OpenACC directives accepted may be
+//   found in the OpenACC Application Programming Interface manual, version 2.6"; _OPENACC is 201711 (2.6). No list of OpenACC gaps
+//   is documented.
+// - other families: NVHPC 25.11/26.9 compile and run it correctly.
+// - gate and confirmer: 4 cells (2 gcc_g90, 2 gcc_sm80), each confirmed in the gate's four environments (a-d;
+//   results/gcc/gate-tioga/ and gate-wingtip/ verdicts.jsonl); confirmer verdicts (results/gcc/confirm/batch.gcc_*.jsonl):
+//   compiler_bug (R11-compile-rejection) 2, needs_human (R12b-compile-undecided) 2
+// - catalog programs (2): acc34-c-clause-gang-dim, acc34-c-clause-gang-dim-binop
+// - legality: the catalog programs are legal by construction (offload.engine.gen, c_gen and acc_gen
+//   check every program against the catalog rules and the offload scope as it is built; no
+//   compiler). GCC is a compiler under test only: never a legality witness, here or for another
+//   family's case (catalog/machines.yaml under_test_only).
+// Generated by compliance.acc_c_gen (OpenACC 3.4, C11): the C port (offload.engine.f2c) of acc34-clause-gang-dim. Do not edit.
+// id: acc34-c-clause-gang-dim
+// primary atom: acc.clause.gang.dim
+// legal: yes
+// observable: yes
+// ran_on_host: inside the compute region of interest (acc_on_device)
+// evidence: equivalent_default
+// needs: none
+// std: c11
+// oracle: without the loop construct every gang of the parallel region executes every iteration (gang-redundant mode), and the
+// atomic update adds the value once per gang
+// no oracle (equivalent_default): dimension one is the gang clause's dimension without dim
+// basis: OpenACC 3.4 §2.9.2, p.66: "The associated dimension is the value of the dim argument, if it appears, or is dimension one."
+// C: the atomic update is written x += expr; the port's x = x + e1 + e2 is also a legal 3.4 §2.12 form (mathematically equivalent
+// to x + (e1 + e2)) and is kept as acc34-c-clause-gang-dim-binop
+#include <stdio.h>
+#include <stdbool.h>
+#include <openacc.h>
+
+enum { n = 64 };
+
+int main(void) {
+  int a[n];
+  int b[n];
+  int ref[n];
+  int host_flag;
+  bool ok;
+  for (int i = 1; i <= n; i++) {
+    a[i - 1] = i;
+    b[i - 1] = 0;
+    ref[i - 1] = 2 * i + 1;
+  }
+  host_flag = 1;
+  #pragma acc parallel num_gangs(4) copyin(a) copy(b) copy(host_flag)
+  {
+    #pragma acc loop gang(dim: 1)
+    for (int i = 1; i <= n; i++) {
+      if (i == 1) host_flag = (acc_on_device(acc_device_host) ? 1 : 0);
+      #pragma acc atomic update
+      b[i - 1] += 2 * a[i - 1] + 1;
+    }
+  }
+  bool t1_ = true;
+  for (int k2_ = 0; k2_ < n; k2_++)
+    t1_ = t1_ && (b[k2_] == ref[k2_]);
+  ok = t1_;
+  printf("RESULT ran_on_host=%d check=%s\n", host_flag, ok ? "pass" : "fail");
+  return 0;
+}
+// site:
+// title: OpenACC 3.3 gang(dim:) is rejected (C)
+// summary: GCC 16.2 rejects the dim argument of the gang clause in C ("'dim' undeclared"), an OpenACC 3.3 form; GCC documents
+// + OpenACC 2.6. NVHPC compiles and runs the program. (The C collapse(force:) program is rejected by every compiler under test, so
+// + it is not part of this finding.)
+// same_as: gcc/gcc-acc-gang-dim-collapse-force-rejected
+// end site

offload/_root/data/findings/gcc/gcc-acc-c-link-in-routine-rejected.c

@@ -0,0 +1,82 @@
+// # Finding (GCC 16.2): a declare link variable used in an OpenACC routine is rejected (C); the reproducer is the catalog program
+//   acc34-c-clause-link
+//
+// - 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; OMP_TARGET_OFFLOAD=mandatory
+// - build: gcc -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: rejected: with .link. clause used in .routine. function
+// - observed: `error: 'lv' with 'link' clause used in 'routine' function` on both GPUs.
+// - expected: compiles; `RESULT ran_on_host=0 check=pass`
+// - spec: "The global variable or common block variables may be used in accelerator routines" (OpenACC 3.4 §2.13.3 l.3083-3084),
+//   for a variable in a declare link clause; the device copy exists while a data clause holds it (l.3079-3081), here the parallel
+//   loop's copyin(lv).
+// - GCC 16.2 documentation (libgomp.texi "Enabling OpenACC"): "A complete description of all OpenACC directives accepted may be
+//   found in the OpenACC Application Programming Interface manual, version 2.6"; _OPENACC is 201711 (2.6). No list of OpenACC gaps
+//   is documented.
+// - other families: NVHPC 25.11/26.9 compile it and give a wrong answer (not studied here).
+// - gate and confirmer: 2 cells (1 gcc_g90, 1 gcc_sm80), each confirmed in the gate's four environments (a-d;
+//   results/gcc/gate-tioga/ and gate-wingtip/ verdicts.jsonl); confirmer verdicts (results/gcc/confirm/batch.gcc_*.jsonl):
+//   compiler_bug (R11-compile-rejection) 2
+// - catalog programs (1): acc34-c-clause-link
+// - legality: the catalog programs are legal by construction (offload.engine.gen, c_gen and acc_gen
+//   check every program against the catalog rules and the offload scope as it is built; no
+//   compiler). GCC is a compiler under test only: never a legality witness, here or for another
+//   family's case (catalog/machines.yaml under_test_only).
+// Generated by compliance.acc_c_gen (OpenACC 3.4, C11): the C port (offload.engine.f2c) of acc34-clause-link. Do not edit.
+// id: acc34-c-clause-link
+// primary atom: acc.clause.link
+// legal: yes
+// observable: yes
+// ran_on_host: inside the compute region of interest (acc_on_device)
+// evidence: construct
+// needs: none
+// std: c11
+#include <stdio.h>
+#include <stdbool.h>
+#include <openacc.h>
+
+enum { n = 64 };
+int lv[64];
+#pragma acc declare link(lv)
+#pragma acc routine seq
+int get_lv(int k) {
+  int r_;
+  r_ = lv[k - 1];
+  return r_;
+}
+
+int main(void) {
+  int a[n];
+  int b[n];
+  int ref[n];
+  int host_flag;
+  bool ok;
+  for (int i = 1; i <= n; i++) {
+    a[i - 1] = i;
+    b[i - 1] = 0;
+    ref[i - 1] = 2 * i + 1;
+  }
+  host_flag = 1;
+  for (int i = 1; i <= n; i++) {
+    lv[i - 1] = 2 * i + 1;
+  }
+  #pragma acc parallel loop copyin(a) copyout(b) copy(host_flag) copyin(lv)
+  for (int i = 1; i <= n; i++) {
+    if (i == 1) host_flag = (acc_on_device(acc_device_host) ? 1 : 0);
+    b[i - 1] = get_lv(a[i - 1]);
+  }
+  bool t1_ = true;
+  for (int k2_ = 0; k2_ < n; k2_++)
+    t1_ = t1_ && (b[k2_] == ref[k2_]);
+  ok = t1_;
+  printf("RESULT ran_on_host=%d check=%s\n", host_flag, ok ? "pass" : "fail");
+  return 0;
+}
+// site:
+// title: OpenACC: a declare link variable used in a routine is rejected (C)
+// summary: A variable in a declare link clause may be used in an accelerator routine (OpenACC 3.4 §2.13.3). GCC 16.2 rejects a
+// + routine seq procedure that reads such a variable: "'lv' with 'link' clause used in 'routine' function", in Fortran and C. CCE
+// + compiles and runs the Fortran program.
+// same_as: gcc/gcc-acc-link-in-routine-rejected
+// end site

offload/_root/data/findings/gcc/gcc-acc-detach-delete-attach-underflow.f90

@@ -0,0 +1,66 @@
+! # Finding (GCC 16.2): OpenACC exit data detach, then exit data delete: "attach count underflow"
+!
+! - 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; OMP_TARGET_OFFLOAD=mandatory
+! - 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: attach count underflow
+! - observed: `libgomp: attach count underflow` and exit 1 at the exit data delete, in every run on both GPUs (this file: gcc_sm80
+!   and gcc_g90, 5 of 5 each with OMP_TARGET_OFFLOAD mandatory and 5 of 5 unset; results/gcc/<tc>/probes-findings.jsonl); the
+!   parallel loop before it ran on the device.
+! - expected: `sum= 2144`, then `RESULT ran_on_host=0 check=pass`
+! - rule: in OpenACC 2.6, the version GCC documents, the delete clause performs a detach action, and "If the current device is a
+!   shared memory device, or if var is not present on the device, or if the attachment counter for var for the pointer is zero, no
+!   action is taken. Otherwise, the attachment counter for the pointer var is decremented" (OpenACC 2.6, section 2.7.2 "Detach
+!   Action", margin lines 1115-1122; the same sentence in OpenACC 3.0, 3.2 and 3.3, the last at margin lines 1710-1711). After exit
+!   data detach the attachment counter is zero, so the delete leaves it alone. OpenACC 3.4 rewords the actions with the same intent:
+!   the delete clause performs a decrement counter action on the attachment counter (OpenACC 3.4 §2.7.12 l.2022-2025), "If the
+!   reference counter is already zero, its value is left unchanged" (§2.7.2 l.1733-1735), and a detach pointer action at a zero
+!   counter is defined (§2.7.2 l.1794-1796); the data clause errors (§2.7.3) name no attachment-counter error.
+! - same-compiler control (correct: `sum= 2144`, 5 of 5 runs on each GPU): the same program without the exit data detach
+!   (controls/gcc-acc{,-c}-detach-control.{f90,c}).
+! - other families: CCE 19/20/21 (Fortran, MI300A and MI250X) and NVHPC 25.11/26.9 (both languages, separate and managed memory) run
+!   the catalog programs acc34-clause-detach and acc34-c-clause-detach to the end (their check cannot see the detach: unobservable).
+!   The site's finding matrix runs this file on every compiler.
+! - gate and confirmer: 2 cells (1 gcc_g90, 1 gcc_sm80), each confirmed in the gate's four environments (a-d;
+!   results/gcc/gate-tioga/ and gate-wingtip/ verdicts.jsonl); confirmer verdicts (results/gcc/confirm/batch.gcc_*.jsonl):
+!   needs_human (R22-expected-weak) 2
+! - catalog programs (1): acc34-clause-detach
+! - legality: read against the spec (the rule above); the catalog programs of the list are legal by construction
+!   (offload.engine.gen,
+!   c_gen and acc_gen; no compiler). GCC is a compiler under test only and never a legality witness.
+program detach_then_delete
+  use openacc, only: acc_device_host, acc_on_device
+  implicit none
+  integer, parameter :: n = 64
+  type :: holder
+    integer, allocatable :: v(:)
+  end type holder
+  type(holder) :: h
+  integer :: b(n)
+  integer :: i, host_flag
+  allocate(h%v(n))
+  h%v = 1
+  b = 0
+  host_flag = 1
+  !$acc enter data copyin(h)
+  !$acc enter data copyin(h%v)
+  !$acc parallel loop copyout(b) copy(host_flag) present(h)
+  do i = 1, n
+    if (i == 1) host_flag = merge(1, 0, acc_on_device(acc_device_host))
+    b(i) = i + h%v(i)
+  end do
+  !$acc exit data detach(h%v)
+  !$acc exit data delete(h%v)
+  !$acc exit data delete(h)
+  print '(a,i0)', 'sum= ', sum(b)
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', sum(b) == 2144)
+end program detach_then_delete
+! site:
+! title: OpenACC: exit data delete after exit data detach stops with "attach count underflow"
+! summary: After exit data detach of an attached member pointer, exit data delete of its target should leave the attachment counter
+! + at zero and free the data. GCC 16.2's libgomp stops the program instead with "attach count underflow" (exit 1), in Fortran and
+! + C, on the MI250X and the A100; without the detach the same program runs correctly. OpenACC 2.6, the version GCC documents, says
+! + a detach action at a zero attachment counter takes no action.
+! control: gcc/controls/gcc-acc-detach-control.f90 the same program without the exit data detach
+! end site

offload/_root/data/findings/gcc/gcc-acc-gang-dim-collapse-force-rejected.f90

@@ -0,0 +1,69 @@
+! # Finding (GCC 16.2): OpenACC 3.3 gang(dim:) and collapse(force:) are rejected (Fortran); the reproducer is the catalog program
+!   acc34-clause-collapse-force
+!
+! - 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; OMP_TARGET_OFFLOAD=mandatory
+! - 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: rejected
+! - observed: `Error: Invalid expression after 'collapse(' at (1)` (gang(dim:): `Failed to match clause`), on both GPUs.
+! - expected: compiles; `RESULT ran_on_host=0 check=pass`
+! - spec: the force modifier (OpenACC 3.4 §2.9.1 l.2340-2341: "If the force modifier does not appear, then the associated loops must
+!   be tightly nested"; added in 3.3: OpenACC 3.4's "Changes from Version 3.2 to 3.3", margin line 807, and OpenACC 3.3's own,
+!   margin line 787) and the dim argument of gang (§2.9.2 l.2371; added in 3.3, "Changes from Version 3.2 to 3.3", margin line 800).
+! - GCC 16.2 documentation (libgomp.texi "Enabling OpenACC"): "A complete description of all OpenACC directives accepted may be
+!   found in the OpenACC Application Programming Interface manual, version 2.6"; _OPENACC is 201711 (2.6). No list of OpenACC gaps
+!   is documented.
+! - other families: CCE 21 and NVHPC 25.11/26.9 compile and run the collapse(force:) program (CCE 19/20 reject it); every compiler
+!   under test fails the Fortran gang(dim:) program.
+! - gate and confirmer: 4 cells (2 gcc_g90, 2 gcc_sm80), each confirmed in the gate's four environments (a-d;
+!   results/gcc/gate-tioga/ and gate-wingtip/ verdicts.jsonl); confirmer verdicts (results/gcc/confirm/batch.gcc_*.jsonl):
+!   compiler_bug (R11-compile-rejection) 2, needs_human (R12b-compile-undecided) 2
+! - catalog programs (2): acc34-clause-collapse-force, acc34-clause-gang-dim
+! - legality: the catalog programs are legal by construction (offload.engine.gen, c_gen and acc_gen
+!   check every program against the catalog rules and the offload scope as it is built; no
+!   compiler). GCC is a compiler under test only: never a legality witness, here or for another
+!   family's case (catalog/machines.yaml under_test_only).
+! Generated by compliance.gen (OpenACC 3.4, free-form Fortran). Do not edit.
+! id: acc34-clause-collapse-force
+! primary atom: acc.clause.collapse.force
+! legal: yes
+! observable: yes
+! ran_on_host: inside the compute region of interest (acc_on_device)
+! evidence: unverified
+! needs: none
+! std: f2008
+! unverified (needs_other_infrastructure): collapse(force: 2) decides which gang, worker or vector lane runs an iteration; no
+! OpenACC routine reports it (the result of a correct loop is the same under every schedule)
+program gen_prog
+  use openacc, only: acc_device_host, acc_on_device
+  implicit none
+  integer, parameter :: n = 64
+  integer, allocatable, target :: a(:), b(:)
+  integer :: ref(n)
+  integer :: i, host_flag
+  logical :: ok
+  integer :: j, k
+  allocate(a(n), b(n))
+  do i = 1, n
+    a(i) = i
+    b(i) = 0
+    ref(i) = 2*i + 1
+  end do
+  host_flag = 1
+  !$acc parallel loop copyin(a) copyout(b) copy(host_flag) collapse(force: 2)
+  do j = 1, 8
+    do k = 1, 8
+      if (j == 1 .and. k == 1) host_flag = merge(1, 0, acc_on_device(acc_device_host))
+      b((j - 1)*8 + k) = 2*a((j - 1)*8 + k) + 1
+    end do
+  end do
+  ok = all(b == ref)
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', ok)
+  deallocate(a, b)
+end program gen_prog
+! site:
+! title: OpenACC 3.3 gang(dim:) and collapse(force:) are rejected (newer than GCC's OpenACC 2.6)
+! summary: GCC 16.2 rejects two OpenACC 3.3 loop forms: the dim argument of the gang clause and the force modifier of collapse. GCC
+! + documents OpenACC 2.6, so both are newer than its claim.
+! end site

offload/_root/data/findings/gcc/gcc-acc-init-set-shutdown-rejected.f90

@@ -0,0 +1,70 @@
+! # Finding (GCC 16.2): gfortran does not accept the OpenACC init, set and shutdown directives; the reproducer is the catalog
+!   program acc34-directive-init
+!
+! - 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; OMP_TARGET_OFFLOAD=mandatory
+! - 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: rejected: Unclassifiable OpenACC directive
+! - observed: `Error: Unclassifiable OpenACC directive at (1)` at `!$acc init` (also `!$acc set`, `!$acc shutdown`, and set's
+!   default_async and device_num clauses), on both GPUs. The C programs of the same directives compile.
+! - expected: compiles; `RESULT ran_on_host=0 check=pass`
+! - spec: the init directive (OpenACC 3.4 §2.14.1 l.3089-3100), "In Fortran the syntax of the init directive is: !$acc init
+!   [clause-list]"; the shutdown directive (§2.14.2) and the set directive (§2.14.3). They were added in OpenACC 2.5 (the
+!   specification's "Changes from Version 2.0 to 2.5", margin lines 590-591).
+! - GCC 16.2 documentation (libgomp.texi "Enabling OpenACC"): "A complete description of all OpenACC directives accepted may be
+!   found in the OpenACC Application Programming Interface manual, version 2.6"; _OPENACC is 201711 (2.6). No list of OpenACC gaps
+!   is documented.
+! - other families: NVHPC 25.11/26.9 compile and run the programs (separate and managed memory); CCE 19/20/21 compile them and abort
+!   at run time (cce-acc-init-set-runtime-assert.f90).
+! - gate and confirmer: 10 cells (5 gcc_g90, 5 gcc_sm80), each confirmed in the gate's four environments (a-d;
+!   results/gcc/gate-tioga/ and gate-wingtip/ verdicts.jsonl); confirmer verdicts (results/gcc/confirm/batch.gcc_*.jsonl):
+!   compiler_bug (R11-compile-rejection) 10
+! - catalog programs (5): acc34-clause-default_async, acc34-clause-device_num, acc34-directive-init, acc34-directive-set,
+!   acc34-directive-shutdown
+! - legality: the catalog programs are legal by construction (offload.engine.gen, c_gen and acc_gen
+!   check every program against the catalog rules and the offload scope as it is built; no
+!   compiler). GCC is a compiler under test only: never a legality witness, here or for another
+!   family's case (catalog/machines.yaml under_test_only).
+! Generated by compliance.gen (OpenACC 3.4, free-form Fortran). Do not edit.
+! id: acc34-directive-init
+! primary atom: acc.directive.init
+! legal: yes
+! observable: no (unverified: the check covers the device kernel, not the atom)
+! ran_on_host: inside the compute region of interest (acc_on_device)
+! evidence: unverified
+! needs: none
+! std: f2008
+! unverified (needs_other_infrastructure): initialisation is observable only as timing or through the profiling interface (3.4
+! chapter 5); the runtime initialises on first use anyway
+program gen_prog
+  use openacc, only: acc_device_host, acc_on_device
+  implicit none
+  integer, parameter :: n = 64
+  integer, allocatable, target :: a(:), b(:)
+  integer :: ref(n)
+  integer :: i, host_flag
+  logical :: ok
+  allocate(a(n), b(n))
+  do i = 1, n
+    a(i) = i
+    b(i) = 0
+    ref(i) = 2*i + 1
+  end do
+  host_flag = 1
+  !$acc init
+  !$acc parallel loop copyin(a) copyout(b) copy(host_flag)
+  do i = 1, n
+    if (i == 1) host_flag = merge(1, 0, acc_on_device(acc_device_host))
+    b(i) = 2*a(i) + 1
+  end do
+  ok = all(b == ref)
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', ok)
+  deallocate(a, b)
+end program gen_prog
+! site:
+! title: gfortran: OpenACC init, set and shutdown directives are not accepted ("Unclassifiable OpenACC directive")
+! summary: GCC 16.2's Fortran front end does not parse the OpenACC init, set and shutdown directives ("Unclassifiable OpenACC
+! + directive"); the C front end accepts them. These directives are part of OpenACC 2.5, and GCC documents OpenACC 2.6. NVHPC
+! + compiles and runs the programs.
+! end site