offtarget 0.1.0__py3-none-any.whl

offload/_root/data/findings/clang-c-linear-directive-name-hang.c

@@ -0,0 +1,30 @@
+/* Finding (C): a directive-name modifier in a linear clause sends
+   the clang front end into an endless loop.
+
+   Legal OpenMP 6.0 C: linear(x: for, step(2)) names the directive the
+   clause applies to (6.0 §5.4, p.174: "The directive-name-modifier is a
+   universal modifier that can be used on any clause"; linear, 6.0
+   §7.5.6, p.232). Expected: compiles
+   (or, for a compiler without the 6.0 modifier, one diagnostic).
+
+   Observed (2026-10-19): AFAR amdclang 24.0.0git and CCE craycc 19.0.0
+   (the omp60-c-clause-linear-directive_name program: also 20.0.2 and
+   21.0.3) print "error: expected expression" at the `for` twenty times,
+   then "fatal error: too many errors emitted, stopping now", and do not
+   exit: killed after 40 s with -fsyntax-only (the matrix: compile
+   timeout on all four toolchains). Without `for,` it compiles at once.
+
+   amdclang -fopenmp -fopenmp-version=60 -fsyntax-only
+   craycc -fopenmp -fopenmp-version=60 -fsyntax-only */
+int main(void) {
+  int x = 0, b[8];
+  #pragma omp parallel for linear(x: for, step(2))
+  for (int i = 0; i < 8; i++) { b[i] = x; x += 2; }
+  return b[1];
+}
+// site:
+// title: craycc -fopenmp-version=60: linear(x: for, step(2)) sends the front end into an endless loop after "too many errors"
+// control: ../vendor/checks/src/other/control/clang-c-linear-directive-name-hang-control.c linear(x: step(2)) without the
+// + directive-name
+// + modifier
+// end site

offload/_root/data/findings/clang-c-map-iterator-omp51.c

@@ -0,0 +1,51 @@
+/* Finding (C), reproducer replaced: at OpenMP 5.1
+   (the default of both clang C front ends) the iterator map-type modifier
+   is rejected.
+
+   Legal OpenMP 5.1 C: iterator(iterators-definition) is a map-type-modifier
+   of the map clause (5.1 §2.21.7.1 p.347). The iterator it = 0:1 has the
+   one value 0 (C ranges exclude the end, 5.1 §2.1.6 p.49), so the map is
+   map(tofrom: a[0:n]); with one instance no two instances share a
+   containing array (5.1 §2.21.7.1 p.353: "the list item instances that
+   would result from different values of the iterator must not have the
+   same containing array"). The first reproducer, map(iterator(it = 0:n),
+   tofrom: a[it]) as in omp_vv test_target_map_iterators.c, broke that
+   restriction and was withdrawn.
+   Expected: "RESULT ran_on_host=0 check=pass".
+
+   Observed (tuolumne, MI300A, -O2, HSA_XNACK 1 and 0, 3 runs each,
+   2026-10-22, data/evidence/triage_probe/map_iter.c, results/t27b/probes_fr1.jsonl):
+   - AFAR amdclang 24.0.0git and CCE craycc 19.0.0, 20.0.2, 21.0.3, with
+     their default flags and with -fopenmp-version=51: "error: incorrect
+     map type modifier, expected one of: 'always', 'close', 'mapper',
+     'present', 'ompx_hold'".
+   - At -fopenmp-version=52: AFAR correct in both modes; CCE craycc 19, 20
+     and 21 crash in the front end (internal compiler error, "clang
+     frontend command failed due to signal").
+   The AMD clang status table at the AFAR commit lists "device | iterators
+   in map clause or motion clauses | done" in its 5.1 section.
+
+   amdclang -fopenmp --offload-arch=gfx942 [-fopenmp-version=51] -O2
+   craycc -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa
+          -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx942 -O2 */
+#include <stdio.h>
+#include <omp.h>
+enum { n = 8 };
+int main(void) {
+  int a[n], bad = 0, host_flag = 1;
+  for (int i = 0; i < n; i++) a[i] = i;
+  #pragma omp target map(iterator(it = 0:1), tofrom: a[it:n]) map(tofrom: host_flag)
+  {
+    host_flag = omp_is_initial_device() ? 1 : 0;
+    for (int i = 0; i < n; i++) a[i] += 1;
+  }
+  for (int i = 0; i < n; i++) bad += a[i] != i + 1;
+  printf("RESULT ran_on_host=%d check=%s\n", host_flag, bad ? "fail" : "pass");
+  return 0;
+}
+// site:
+// title: craycc/ftn: OpenMP 5.1/5.2/6.0 forms HPE does not claim are rejected, and some crash the compiler instead of a diagnostic
+// control: ../vendor/checks/src/other/control/clang-c-map-iterator-omp51-control.c map(tofrom: a[0:n]) without the iterator
+// + modifier
+// same_as: catalog/cce-c-map-iterator-ice
+// end site

offload/_root/data/findings/clang-c-shared-declare-target-combined.c

@@ -0,0 +1,58 @@
+/* Finding (C): a declare target variable listed in shared on a
+   combined target construct is read with its host value.
+
+   Legal OpenMP 5.2 / 6.0 C. on_dev is a declare target variable (5.2
+   §7.8.1); the first target region sets its device copy to 1 (the host
+   copy stays 0). In the second region the shared clause applies only to
+   the teams leaf (5.2 §17.2: shared applies to the leaves that permit it,
+   target does not), so on_dev there is the target region's on_dev: the
+   device copy, which is present (implicitly map(tofrom), 5.2 §5.8.1: no
+   transfer for a present variable). Expected b[1] = 2*1 + 1 = 3, the same
+   as the third region (no shared clause).
+
+   Observed (HSA_XNACK 0 and 1, -O2): AFAR amdclang 24.0.0git, CCE craycc
+   19.0.0, 20.0.2 and 21.0.3 all print b[1]=2 (the host value 0) and
+   c[1]=3. The fourth region (teams loop nested in a target region, the
+   shared clause on teams; expected d[1]=3): CCE 19 and 21 print d[1]=3,
+   AFAR prints an indeterminate value (d[1]=1276187178 here), which makes
+   omp52/60-c-directive-teams_loop wrong_answer on AFAR. AFAR amdflang
+   and CCE ftn run the Fortran form of the same program
+   (omp52-directive-target_teams_loop: shared(a, b, on_dev) under
+   default(none)) correctly; the C ports of the five probe-region programs
+   (target parallel for simd, target parallel loop, target teams
+   distribute parallel for simd, target teams loop, 6.0 target teams
+   distribute simd) fail on every toolchain because of this.
+
+   amdclang -fopenmp --offload-arch=gfx942 -fopenmp-version=52 -O2
+   craycc -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa
+          -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx942 -O2 */
+#include <stdio.h>
+#include <omp.h>
+int on_dev = 0;
+#pragma omp declare target(on_dev)
+int main(void) {
+  int a[64], b[64], c[64], d[64];
+  for (int i = 0; i < 64; i++) { a[i] = i; b[i] = 0; c[i] = 0; d[i] = 0; }
+  #pragma omp target
+  { on_dev = 1; }
+  #pragma omp target teams loop map(to: a) map(from: b) shared(a, b, on_dev)
+  for (int i = 0; i < 64; i++) b[i] = 2 * a[i] + on_dev;
+  #pragma omp target teams loop map(to: a) map(from: c)
+  for (int i = 0; i < 64; i++) c[i] = 2 * a[i] + on_dev;
+  #pragma omp target map(to: a) map(from: d)
+  {
+    #pragma omp teams loop shared(a, d, on_dev)
+    for (int i = 0; i < 64; i++) d[i] = 2 * a[i] + on_dev;
+  }
+  printf("with shared(on_dev): b[1]=%d  without: c[1]=%d  teams loop in "
+         "target with shared(on_dev): d[1]=%d (device copy is 1, host copy "
+         "%d)\n", b[1], c[1], d[1], on_dev);
+  return 0;
+}
+// site:
+// title: craycc: a declare target variable listed in shared on target teams loop is read with its host value
+// control: ../vendor/checks/src/other/control/clang-c-shared-declare-target-combined-control.c shared(a, b, on_dev) removed from
+// + the
+// + first target
+// + teams loop
+// end site

offload/_root/data/findings/dataenv/cce-value-dummy-target-write-visible.f90

@@ -0,0 +1,74 @@
+! # Finding: at -O2, CCE ftn 19/20/21 make a target region's write to a VALUE dummy
+! # visible to the host (no transfer of the dummy; it is firstprivate in the region)
+!
+! - compilers: CCE ftn 19.0.0, 20.0.2, 21.0.3 (MI300A gfx942), -O2 and -O3, HSA_XNACK 0 and 1
+! - expected: rd= 5 vout= 101 dev= 1
+! - actual: rd= 5 vout= 203 dev= 1 (every run: 3 repeats per cell, CCE 19/20/21 x XNACK 0/1 x -O2/-O3)
+! - rule: v is a scalar dummy with the VALUE attribute, without the TARGET, ALLOCATABLE or POINTER attribute,
+!   in no clause of the target construct, so it is not mapped: "If the above rules do not apply then a
+!   scalar variable is not mapped but instead has an implicit data-sharing attribute of firstprivate"
+!   (OpenMP 5.2 §5.8.1 p.149 l.8-9; 5.0 §2.19.7 p.315 l.9-10; 6.0 §7.9.3 p.277 l.22-23), and "In a target
+!   construct, variables that are not mapped after applying data-mapping attribute rules (see Section 5.8)
+!   are firstprivate" (5.2 §5.1.1 p.99 l.19-20). The region's v = 2*v + 1 writes its private copy, so the
+!   procedure's v is still 101 after the region and vout = v returns 101. (A VALUE scalar is Fortran 2003;
+!   OpenMP 5.0 §1.7 lists only the Fortran 2008 extension of VALUE as unspecified.)
+! - what happens (not a map and not a copy-back): with CRAY_ACC_DEBUG=2 (CCE 19, HSA_XNACK 0) the -O2 build
+!   of results/dataenv/probe_fr1/vd_write.f90 (this program without its header and its dev region)
+!   launches `p_$ck_L23_3` from the call site at its line 23 (sub is inlined into the main program) and
+!   transfers only `r` ("allocate 'r'", then "copy to host, free 'r'"); nothing of v is transferred, yet
+!   the host reads 203. The -O0 build launches `sub_$ck_L6_1`, transfers the same `r`, and the host reads
+!   101.
+!   (trace: results/dataenv/probe_fr1/trace.out; review, section 5)
+! - conditions (each a one-change variant, CCE 19/20/21, HSA_XNACK 0 and 1, results/dataenv/probe_fr1/):
+!   - correct at -O0 and -O1; wrong at -O2 and -O3;
+!   - correct when the region only reads v (r = v);
+!   - correct when the region also calls omp_is_initial_device();
+!   - wrong with sub a module procedure too (the generator's form, the trial's 9 CCE cells, gfx942 and
+!     gfx90a, both modes: results/dataenv/pilot_all/).
+! - same-compiler controls (all correct, -O2): firstprivate(v) on the target construct; v a by-reference
+!   intent(inout) dummy instead of VALUE; a local copy u = v written in the region instead of v.
+! - other families: AFAR amdflang 24.0.0git (drop 24.3.0) correct on this file at -O0 to -O3, both modes;
+!   NVHPC 25.11 and 26.9 (A100, separate and managed) correct on the generator's module-procedure form
+!   (the trial's rows); this file was not run on NVHPC.
+! - legality: offload.engine.prerun.check accepts it (offload.engine.rules with the race rule, and the AFAR flang
+!   front end); the region is executed by one initial thread; no compiler under test, gfortran or gcc is a
+!   legality witness.
+! - found by: the data-environment pilot, rule omp-target-value-dummy-firstprivate
+!   (catalog/dataenv_rules.yaml); gate verdict confirmed on all 9 CCE cells.
+!   This 22-line reproducer is the reviewer's.
+! CCE:  ftn -fopenmp -O2 (module load cce/<v> craype-accel-amd-gfx942 rocm/<r>; module unload cray-mpich)
+! AFAR: amdflang -fopenmp --offload-arch=gfx942 -O2
+! Run:  OMP_TARGET_OFFLOAD=mandatory ./a.out
+subroutine sub(v, rd, vout)
+  integer, value :: v
+  integer, intent(out) :: rd, vout
+  integer :: r
+  r = -1
+  !$omp target map(from: r)
+    v = 2*v + 1
+    r = 5
+  !$omp end target
+  rd = r
+  vout = v          ! CCE 19/20/21 -O2: 203; expected 101
+end subroutine sub
+
+program value_dummy_target_write
+  use omp_lib, only: omp_is_initial_device
+  implicit none
+  interface
+    subroutine sub(v, rd, vout)
+      integer, value :: v
+      integer, intent(out) :: rd, vout
+    end subroutine sub
+  end interface
+  integer :: rd, vout, dev
+  dev = -1
+  !$omp target map(from: dev)
+    dev = merge(0, 1, omp_is_initial_device())
+  !$omp end target
+  call sub(101, rd, vout)
+  print '(a,i0,a,i0,a,i0)', 'rd= ', rd, ' vout= ', vout, ' dev= ', dev
+end program value_dummy_target_write
+! site:
+! title: ftn at -O2: a target region's write to a VALUE dummy, firstprivate there, becomes visible to the host
+! end site

offload/_root/data/findings/defaultmap-none-loop-variable.f90

@@ -0,0 +1,69 @@
+! Finding: defaultmap(none) on a target construct whose every
+! referenced variable has a data-environment attribute is rejected by every
+! compiler.
+!
+! Legal OpenMP 5.2: "If implicit-behavior is none, each variable that is
+! specified by variable-category and is referenced in the construct but does
+! not have a predetermined data-sharing and does not appear in an enter or
+! link clause on a declare target directive must be explicitly listed in a
+! data-environment attribute clause on the construct" (5.2 §5.8.7 p.162).
+! a, b and host_flag are mapped; n is a named constant, not a variable; i is
+! listed in private(i), a data-environment attribute clause (whether it is
+! also predetermined private as a loop iteration variable, 5.2 §5.1.1 p.97,
+! depends on reading target as a task generating construct; the finding
+! does not rest on it). Expected: "RESULT ran_on_host=0 check=pass".
+!
+! Legality rests on the quoted spec text only (registry
+! RUL-LEGAL-DEFAULTMAP-NONE): there is no independent compiler witness.
+! Cited gfortran 13.3.1 -fopenmp as one; the maintainer withdrew
+! gfortran/gcc -fopenmp as offload legality witnesses on 2026-10-23 (final
+! review 3, data/reports/rulings.md), so the catalog cells are
+! unsupported_everywhere (every family rejects), not compiler_bug (R12a
+! cannot fire without a witness). The variant without private(i)
+! (data/evidence/triage_probe/dmap_none_noi.f90) is contested.
+! (2026-10-24): NVHPC 25.11 and 26.9 (wingtip, the configured
+! witness) accept the omp50/52/60-clause-defaultmap-none programs, but
+! that is no witness either (ruling R2): nvc also
+! compiles and runs the illegal C defaultmap(none) variants
+! (omp52/60-c-illegal-defaultmap-map-003, a referenced variable not
+! listed), and nvfortran compiles a Fortran target defaultmap(none) that
+! references unlisted x and n; NVHPC does not enforce defaultmap(none), so
+! its accept says nothing about legality (offload.engine.confirm.witness
+! uncalibrated; catalog/legality_witness.yaml calibration rows). The cells
+! stay unsupported_everywhere.
+!
+! Observed (tuolumne, MI300A, both memory modes, -O2, 2026-10-22,
+! data/evidence/triage_probe/dmap_none.f90 and dmap_none_noi.f90 (without private(i)),
+! results/t27b/probes.jsonl): every compiler under test rejects this form
+! (and the variant without private(i)):
+! - AFAR amdflang 24.0.0git: "The DEFAULTMAP(NONE) clause requires that 'i'
+!   must be listed in a data-sharing attribute, data-mapping attribute, or
+!   is_device_ptr clause";
+! - CCE 20.0.2, 21.0.3: ftn-1964 "Variable "I" must have its data mapping
+!   attribute explicitly declared because default map(none) was specified";
+! - CCE 19.0.0: ftn-1964 "Variable "B" ..." although b is in map(from: b).
+! The catalog's omp50/52/60-clause-defaultmap-none programs are rejected on
+! every compiler because of it.
+!
+! amdflang -fopenmp --offload-arch=gfx942 -O2; ftn -fopenmp -O2
+program p
+  use omp_lib, only: omp_is_initial_device
+  implicit none
+  integer, parameter :: n = 64
+  integer :: a(n), b(n), i, host_flag
+  a = [(i, i = 1, n)]
+  b = 0
+  host_flag = 1
+  !$omp target map(to: a) map(from: b) map(tofrom: host_flag) defaultmap(none) private(i)
+    host_flag = merge(1, 0, omp_is_initial_device())
+    do i = 1, n
+      b(i) = 2*a(i) + 1
+    end do
+  !$omp end target
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', &
+    merge('pass', 'fail', all(b == 2*a + 1))
+end program p
+! site:
+! title: ftn: defaultmap(none) rejected although every referenced variable has a data-environment attribute (ftn-1964)
+! control: ../vendor/checks/src/other/control/defaultmap-none-loop-variable-control.f90 defaultmap(none) removed
+! end site

offload/_root/data/findings/fortran-loop-bind-thread-in-parallel.f90

@@ -0,0 +1,53 @@
+! loop bind(thread) in a parallel region in a target region: the binding
+! region is not defined and the binding thread set is the encountering
+! thread (5.2 §11.7.1 p.257-258), so every thread of the team runs all n
+! logical iterations ("Each logical iteration is executed once per
+! instance of the loop region that is encountered by exactly one thread
+! that is a member of the binding thread set", 5.2 §11.7 p.257). Each
+! iteration writes its own element hit(i, thread + 1): no data race even
+! though the iterations may execute concurrently.
+! Expected: every thread ran all 64 iterations (0 short).
+! Observed (MI300A, HSA_XNACK 0 and 1, 3 runs each): AFAR flang: 256
+! threads, 1 iteration each for threads 0-3 (the team shares the
+! iterations, as bind(parallel) would); CCE 19, 20, 21 ftn: 37-38, 1, 1, 1
+! at HSA_XNACK=1 and 1 or 2 per thread at HSA_XNACK=0; all 256 threads
+! short. The C form (AMD clang) is correct: 64 per thread.
+! : on CCE the same loop without the loop
+! directive fails too, and the program is correct at -O0: CCE's failure is
+! the sequential-loop defect of cce19-target-parallel-guarded-loop.f90, not
+! a bind(thread) defect. On AFAR it is a bind(thread) defect.
+program bind_thread_repro
+  use omp_lib
+  implicit none
+  integer, parameter :: n = 64
+  integer :: hit(n, 1024), nthr, tid, i, k, short
+  hit = 0
+  nthr = -1
+  !$omp target map(tofrom: hit, nthr)
+    !$omp parallel private(tid)
+      tid = omp_get_thread_num()
+      if (tid == 0) nthr = omp_get_num_threads()
+      !$omp loop bind(thread)
+        do i = 1, n
+          if (tid < 1024) hit(i, tid + 1) = hit(i, tid + 1) + 1
+        end do
+      !$omp end loop
+    !$omp end parallel
+  !$omp end target
+  short = 0
+  do k = 1, min(nthr, 1024)
+    if (sum(hit(:, k)) /= n) short = short + 1
+  end do
+  print '(a,i0,a,4(1x,i0))', 'threads=', nthr, ' iterations run by threads 0-3:', &
+    (sum(hit(:, k)), k = 1, 4)
+  print '(a,i0,a)', 'threads that did not run all 64 iterations: ', short, ' (expected 0)'
+end program bind_thread_repro
+! site:
+! title: ftn -fopenmp: a sequential DO loop executed by one thread of a target parallel region runs only some of its iterations
+! + (-O2)
+! control: ../vendor/checks/src/other/control/fortran-loop-bind-thread-in-parallel-control.f90 the loop directive removed (each
+! + thread
+! + runs a
+! + plain DO loop)
+! same_as: cce19-target-parallel-guarded-loop
+! end site

offload/_root/data/findings/fortran-schedule-static-in-target.f90

@@ -0,0 +1,55 @@
+! Schedule(static, 4) on a parallel do in a target region:
+! "iterations are divided into chunks of size chunk_size, and the chunks
+! are assigned to the threads in the team in a round-robin fashion in the
+! order of the thread number" (5.2 §11.5.3 p.252), so iteration i runs on
+! thread mod((i - 1)/4, T). schedule(static) without a chunk size: "at
+! most one chunk is distributed to each thread" (same page), so each
+! thread's iterations are contiguous.
+! Expected: 0 wrong, 0 second chunks. Observed (MI300A, HSA_XNACK 0 and 1,
+! 3 runs each): AFAR flang, CCE 19, 20 and 21 ftn: 256 threads,
+! tid(1:12) = 0 1 2 ... 11 for both loops (one iteration at a time,
+! round-robin), 997 of 1000 iterations on the wrong thread, 744 second
+! chunks. The C form (sched_repro.c in results/t27a/diag/d2, AMD clang)
+! is correct: tid = 0 0 0 0 1 1 1 1 ...
+program sched_repro
+  use omp_lib
+  implicit none
+  integer, parameter :: m = 1000
+  integer :: tid(m), tid2(m), nthr, i, bad, bad2
+  tid = -1
+  tid2 = -1
+  nthr = -1
+  !$omp target map(from: tid, tid2, nthr)
+    !$omp parallel do schedule(static, 4)
+      do i = 1, m
+        if (i == 1) nthr = omp_get_num_threads()
+        tid(i) = omp_get_thread_num()
+      end do
+    !$omp end parallel do
+    !$omp parallel do schedule(static)
+      do i = 1, m
+        tid2(i) = omp_get_thread_num()
+      end do
+    !$omp end parallel do
+  !$omp end target
+  bad = 0
+  do i = 1, m
+    if (tid(i) /= mod((i - 1)/4, nthr)) bad = bad + 1
+  end do
+  ! static without chunk: at most one chunk (contiguous) per thread
+  bad2 = 0
+  do i = 2, m
+    if (tid2(i) /= tid2(i - 1) .and. any(tid2(1:i - 1) == tid2(i))) bad2 = bad2 + 1
+  end do
+  print '(a,i0,a,12(1x,i0))', 'threads=', nthr, ' static,4 tid(1:12)=', tid(1:12)
+  print '(a,12(1x,i0))', 'static tid(1:12)=', tid2(1:12)
+  print '(a,i0,a,i0,a)', 'static,4 iterations on the wrong thread: ', bad, ' of ', m, ' (expected 0)'
+  print '(a,i0,a)', 'static: iterations starting a second chunk of a thread: ', bad2, ' (expected 0)'
+end program sched_repro
+! site:
+! title: ftn: schedule(static, 4) and schedule(static) on a parallel do in a target region deal iterations out one at a time
+! control: ../vendor/checks/src/other/control/fortran-schedule-static-in-target-control.f90 schedule(static, 1) and its check
+! + (iteration
+! + i on
+! + thread mod(i - 1, T)) instead of schedule(static, 4)
+! end site

offload/_root/data/findings/fresh/cce-common-block-name-in-map-rejected.f90

@@ -0,0 +1,47 @@
+! # Finding (from the data/bench/fresh draft fresh-097): CCE rejects a common block name in a
+!   map clause
+!
+! - source: data/bench/fresh/fresh-097.f90 (GCC Bugzilla 115577 with the reader of GCC PR 115559): a
+!   common block in declare target link, mapped by name on target enter data. CCE rejects the map
+!   clause with or without declare target, with or without a map type, on target enter data and on
+!   target; this reproducer is the shortest form
+! - compilers: CCE 19.0.0, 20.0.2 and 21.0.3 ftn, -fopenmp -O2
+! - expected: compiles and prints wild-check: pass. A Fortran list item may be "a common block name
+!   (enclosed in slashes)" (OpenMP 5.2 §3.2.1 p.61 l.6), and "When a named common block appears in
+!   an OpenMP argument list, it has the same meaning and restrictions as if every explicit member of
+!   the common block appeared in the list" (l.11-13); the map clause takes a locator list (§5.8.3
+!   p.150), whose items are variable list items (§3.2.1 p.61 l.7-8). OpenMP 5.0, which HPE claims in
+!   full ("CCE supports full OpenMP 5.0", intro_openmp(7)), already says it: "A list item is a
+!   variable, array section or common block name (enclosed in slashes) ... a common block name
+!   specified in a data-sharing attribute, a data copying or a data-mapping attribute clause must be
+!   declared to be a common block in the same scoping unit" (5.0 §2.1 p.39 l.11-20)
+! - actual: ftn-534: 'Common block "MYCOMMON" must not be specified on the MAP clause on directive
+!   !$OMP TARGET.' (and "... TARGET ENTER DATA." for the draft), every release, both memory modes
+! - control (same compiler): the members named instead, map(to: A, B, C), compile and print
+!   wild-check: pass (data/reports/fresh-drafts/d097-target-members.f90, d097-members.f90)
+! - other families: AFAR compiles and prints wild-check: pass (MI300A HSA_XNACK 1 and 0; MI250X).
+!   NVHPC 25.11 rejects the draft's declare target link(/mycommon/) as a syntax error and 26.9 says
+!   LINK is not implemented
+! - legality: legal by reading (5.0 and 5.2 text above; the common block is declared in the scoping
+!   unit of the clause)
+! - evidence: results/fresh-drafts/tuo-p1.jsonl, tuo2-q4.jsonl, tuo3-r*-c.jsonl, tioga/tioga-d.jsonl (review)
+program main
+   integer :: A(2), C, r
+   real :: B
+   common /mycommon/ A, B, C
+   A = [1, 2]; B = 2.0; C = 7
+   r = 0
+   !$omp target map(to: /mycommon/) map(from: r)
+     if (A(1) == 1 .and. A(2) == 2 .and. B == 2.0 .and. C == 7) r = 1
+   !$omp end target
+   if (r == 1) then
+     print *, 'wild-check: pass'
+   else
+     print *, 'wild-check: fail'
+   end if
+end program main
+! site:
+! title: ftn: a common block name in a map clause is rejected (ftn-534)
+! control: ../vendor/checks/src/cce/control/cce-common-block-name-in-map-rejected-control.f90 the members named instead: map(to:
+! + A, B, C)
+! end site

offload/_root/data/findings/fresh/cce-if-stop-in-target-ice-one-condition.f90

@@ -0,0 +1,38 @@
+! # Finding (from the data/bench/fresh draft fresh-106): CCE ICE on an IF with one
+!   operand that guards a STOP directly in a target region
+!
+! - the one-operand form of fresh/cce-if-stop-in-target-ice.f90 (see its header for the source):
+!   `if (x /= 1) stop 1` directly in a target region; `if (allocated(j)) stop 1`,
+!   `if (.not. allocated(j)) stop 1` and `if (allocated(j)) error stop 1` give the same ICE
+!   (data/reports/fresh-drafts/d106-e2.f90, d106-e7.f90, d106-e6.f90; CCE 21 rejects the ERROR STOP
+!   instead: "Non-localized coarray control/access statements are not allowed in an OpenMP
+!   explicit region")
+! - compilers: CCE 19.0.0, 20.0.2 and 21.0.3 ftn, -fopenmp -O2 (gfx942 and gfx90a)
+! - expected: compiles and prints x 11 (OpenMP 5.2 §4.3 p.76 l.13-21: "A structured block ... may
+!   contain STOP or ERROR STOP statements"); x is 1 on entry, so the STOP is not reached
+! - actual: INTERNAL COMPILER ERROR "COND PDG 20 with no stmts." (pdgcs/v_fs.c line 2323 in CCE 19,
+!   2325 in CCE 20 and 21)
+! - control (same compiler): `if (x /= 1) x = -100` (data/reports/fresh-drafts/d106-r1-ctl.f90)
+!   compiles and prints x 11
+! - other families: AFAR compiles and prints x 11 (MI300A HSA_XNACK 1 and 0; MI250X)
+! - related: catalog/cce-flang-stop-in-target-crash.f90
+! - legality: legal by reading
+! - evidence: results/fresh-drafts/tuo4-r*.jsonl, tioga/tioga2.jsonl (d106-r1.f90, identical to the
+!   program below), tuo2-q1.jsonl (d106-e3.f90, the same with an unused allocatable) (review)
+program p
+  implicit none
+  integer :: x
+  x = 1
+  !$omp target map(tofrom: x)
+    if (x /= 1) stop 1
+    x = 11
+  !$omp end target
+  print *, 'x', x
+end program p
+! site:
+! title: ftn: an IF statement guarding STOP in device code: the STOP runs although its condition is false (target loop), or an
+! + internal compiler error (directly in a target region)
+! control: ../vendor/checks/src/cce/control/cce-if-stop-in-target-ice-one-condition-control.f90 the IF with an assignment instead
+! + of STOP
+! same_as: catalog/cce-flang-stop-in-target-crash
+! end site

offload/_root/data/findings/fresh/cce-if-stop-in-target-ice.f90

@@ -0,0 +1,43 @@
+! # Finding (from the data/bench/fresh draft fresh-106): CCE ICE on an IF that guards a STOP
+!   directly in a target region
+!
+! - source: data/bench/fresh/fresh-106.f90 (GCC Bugzilla 119905, libgomp map-alloc-comp-11.f90:
+!   recursive allocatable components, checks that end in STOP inside the target region). The ICE
+!   needs neither the derived types nor ALLOCATED: it needs an IF whose action is STOP, directly in
+!   a target region (not inside a loop construct: the catalog's `if (a(i) < 0) stop 1` inside
+!   target teams distribute parallel do compiles, see Related). With two operands joined by .or.
+!   (this file) the ICE is the draft's; with one operand it is another ICE
+!   (fresh/cce-if-stop-in-target-ice-one-condition.f90)
+! - compilers: CCE 19.0.0, 20.0.2 and 21.0.3 ftn, -fopenmp -O2 (gfx942 and gfx90a)
+! - expected: compiles and prints x 11. "A structured block ... may contain STOP or ERROR STOP
+!   statements" (OpenMP 5.2 §4.3 p.76 l.13-21); x is 1 on entry, so the STOP is not reached
+! - actual: INTERNAL COMPILER ERROR "Condition statement not found in condition node"
+!   (pdgcs/v_region.c line 636 in CCE 19 and 20, line 646 in CCE 21), the ICE of the draft
+! - control (same compiler): the same IF with an assignment instead of the STOP,
+!   `if (x /= 1 .or. x > 5) x = -100` (data/reports/fresh-drafts/d106-r2-ctl.f90), compiles and
+!   prints x 11
+! - other families: AFAR compiles and prints x 11 (MI300A HSA_XNACK 1 and 0; MI250X). NVHPC rejects
+!   the draft's recursive allocatable components (a Fortran 2008 feature)
+! - related: catalog/cce-flang-stop-in-target-crash.f90 (an unreached IF ... STOP inside a target
+!   loop compiles, and the device executes the STOP): the same construct, a different outcome,
+!   plausibly the same root cause (the condition of an IF whose action is STOP is lost)
+! - legality: legal by reading
+! - evidence: results/fresh-drafts/tuo4-r*.jsonl, tioga/tioga2.jsonl (d106-r2.f90, identical to the
+!   program below), tuo2-q1.jsonl, tuo3-r*-c.jsonl, tioga/tioga-d.jsonl (d106-e4.f90, the same with an
+!   unused allocatable) (review)
+program p
+  implicit none
+  integer :: x
+  x = 1
+  !$omp target map(tofrom: x)
+    if (x /= 1 .or. x > 5) stop 1
+    x = 11
+  !$omp end target
+  print *, 'x', x
+end program p
+! site:
+! title: ftn: an IF statement guarding STOP in device code: the STOP runs although its condition is false (target loop), or an
+! + internal compiler error (directly in a target region)
+! control: ../vendor/checks/src/cce/control/cce-if-stop-in-target-ice-control.f90 the IF with an assignment instead of STOP
+! same_as: catalog/cce-flang-stop-in-target-crash
+! end site

offload/_root/data/findings/fresh/cce-list-directed-print-in-target-copy-crash.f90

@@ -0,0 +1,40 @@
+! # Finding (from the data/bench/fresh draft fresh-022): CCE 19/20 abort on a list-directed
+!   PRINT in a target region in copy mode
+!
+! - source: data/bench/fresh/fresh-022.f90 (llvm-project issue 166338, the reporter's program unchanged)
+! - compilers: CCE 19.0.0 and 20.0.2 ftn, -fopenmp -O2, OMP_TARGET_OFFLOAD=mandatory; MI300A (gfx942)
+!   at HSA_XNACK=0 and MI250X (gfx90a, Tioga) at HSA_XNACK=0
+! - expected: "Hello, world!" from the device. PRINT is a base-language statement; OpenMP 5.2 places
+!   no restriction on I/O statements in a target region (the restrictions on structured blocks,
+!   §4.3 p.76-77, concern branches into and out of the block), and an implementation is compliant
+!   only if it "compiles and executes all other conforming programs" (§1.6 p.34 l.22-24). HPE
+!   documents the case: "Fortran PRINT
+!   statements are supported, with limitations, when called from OpenMP offload regions compiled for
+!   AMD GPU targets. The current implementation supports PRINT statements with a single scalar value
+!   of type character, integer, real, or complex" (intro_openmp(7), CCE 19.0.0 and 20.0.2,
+!   "Printing from GPU kernels"; data/index/claims/)
+! - actual: CCE 19 and 20 at HSA_XNACK=0: "Memory access fault by GPU node-4 ... Reason: Unknown",
+!   SIGABRT, nothing printed (MI300A three runs each; MI250X). At HSA_XNACK=1 correct. The same with
+!   `print *, 42` (data/reports/fresh-drafts/d022-list-int.f90) and with two list-directed PRINTs
+!   (d022-two-lists.f90)
+! - control (same compiler): the formatted `print '(a)', "Hello, world!"`
+!   (data/reports/fresh-drafts/d022-fmt-literal.f90) prints the line on CCE 19/20 at XNACK 0 and 1.
+!   With a mapped scalar written in the same region the list-directed PRINT also works
+!   (d022-map-only.f90, d022-list-literal-dev.f90): the abort needs a region without other data
+! - other families: AFAR, CCE 21.0.3 and NVHPC 25.11/26.9 (A100, separate and managed memory) print
+!   the line
+! - legality: legal by reading (no OpenMP construct but target; no data)
+! - evidence: results/fresh-drafts/tuo*-*.jsonl, tioga/tioga-a.jsonl, wingtip/nv.jsonl (runs of the review);
+!   the data/bench/fresh ground truth (data/bench/fresh/outcomes.csv: cce19/cce20
+!   copy crash on gfx942 and gfx90a)
+program reproducer
+  implicit none
+  !$omp target
+  print *, "Hello, world!"
+  !$omp end target
+end program reproducer
+! site:
+! title: ftn: a list-directed PRINT in a target region aborts the run in copy mode
+! control: ../vendor/checks/src/cce/control/cce-list-directed-print-in-target-copy-crash-control.f90 a formatted PRINT, print '(a)',
+! + instead of list-directed print *
+! end site

offload/_root/data/findings/fresh/cce19-acc-automatic-array-copyout-copy-crash.f90

@@ -0,0 +1,56 @@
+! # Finding (from the data/bench/fresh draft fresh-084): CCE 19 crashes on a two-dimensional
+!   automatic array in copyout in copy mode (OpenACC)
+!
+! - source: data/bench/fresh/fresh-084.f90 (reconstructed from the ICON workaround at
+!   src/atm_dyn_iconam/mo_nh_supervise.f90, icon-model 8597da45, line 765: an automatic array in
+!   copyout, zeroed in kernels and filled in a parallel loop). Neither the kernels region nor the
+!   copyin array matters; the automatic array's rank does (the one-dimensional form,
+!   data/reports/fresh-drafts/d084-min.f90, is correct)
+! - compilers: CCE 19.0.0 ftn -h acc -O2; MI300A HSA_XNACK=0, MI250X (Tioga) HSA_XNACK=0
+! - expected: s 3150.0. copyout(w) on the data construct allocates w on the device at entry and
+!   transfers it out at exit when the reference counters reach zero (OpenACC 3.4 §2.7.9 p.56
+!   l.1932-1953); the parallel loop writes every element, so w(i, k) = i*k on the host after the
+!   region and the sum over i = 1..20, k = 1..5 is 210 * 15 = 3150
+! - actual: SIGSEGV (exit -11), nothing printed, three runs of three; at HSA_XNACK=1 correct
+! - control (same compiler): w a fixed-size local w(20, 5) instead of the automatic w(nb, nl)
+!   prints s 3150.0 at XNACK 0 and 1 (data/reports/fresh-drafts/d084-min2d-fixed.f90); so do an
+!   allocatable vn_aux in the draft (d084-allocatable.f90) and the one-dimensional automatic array
+!   (d084-min.f90)
+! - other families: CCE 20.0.2 and 21.0.3 print s 3150.0 (both modes); NVHPC 25.11 and 26.9 print
+!   s 3150.0 on this program and run the draft correctly (A100, separate and managed
+!   memory); AFAR has no Fortran OpenACC
+! - legality: legal by reading
+! - evidence: results/fresh-drafts/tuo-p2.jsonl, tuo2-q2.jsonl, tuo3-r*-b.jsonl, tioga/tioga-b.jsonl,
+!   wingtip/nv.jsonl, wingtip/nv4.jsonl (review)
+module m
+  implicit none
+contains
+  subroutine fill(nb, nl, s)
+    integer, intent(in) :: nb, nl
+    real(8), intent(out) :: s
+    real(8) :: w(nb, nl)
+    integer :: i, k
+    !$acc data copyout(w)
+    !$acc parallel loop collapse(2)
+    do k = 1, nl
+      do i = 1, nb
+        w(i, k) = i * k
+      end do
+    end do
+    !$acc end data
+    s = sum(w)
+  end subroutine fill
+end module m
+
+program main
+  use m
+  implicit none
+  real(8) :: s
+  call fill(20, 5, s)
+  print *, 's', s
+end program main
+! site:
+! title: ftn 19 (OpenACC): a two-dimensional automatic array in copyout crashes the run in copy mode
+! control: ../vendor/checks/src/cce/control/cce19-acc-automatic-array-copyout-copy-crash-control.f90 w a fixed-size local array
+! + w(20, 5) instead of the automatic w(nb, nl)
+! end site