offtarget 0.1.0__py3-none-any.whl

offload/_root/data/findings/afar-c-error-directive-in-target-link.c

@@ -0,0 +1,37 @@
+// An error directive with at(compilation) severity(warning) in a
+// target region (OpenMP 6.0 §10.1: at(compilation) acts at compile time
+// only; a warning lets the compilation go on). Expected: the warning, a
+// successful build, "RESULT ... check=pass".
+// Observed (AFAR amdclang 24.0.0git, -fopenmp --offload-arch=gfx942
+// -fopenmp-version=60 -O2, 2026-10-21): the warning is printed twice (host
+// and device pass), then the device link fails: "ld.lld: error: undefined
+// symbol: __kmpc_error >>> referenced by ...img.lto.o:(__omp_offloading_..
+// _main_l..)": the device code calls the runtime error routine, which the
+// device runtime lacks (amdclang lowers at(compilation) to a run-time
+// call: placed in the host part of main the program builds, and its run
+// prints "OMP: Warning #290: ... Encountered user-directed warning: probe",
+// which at(compilation) should not). The Fortran form (amdflang) builds and
+// runs; CCE craycc 19, 20, 21 build and run both placements. Makes the C message, severity and
+// severity.warning programs (6.0) a link failure on AFAR.
+#include <stdio.h>
+#include <omp.h>
+
+int main(void) {
+  int b[64];
+  int host_flag = 1;
+  #pragma omp target map(from: b) map(tofrom: host_flag)
+  {
+    #pragma omp error at(compilation) severity(warning) message("probe")
+    host_flag = omp_is_initial_device();
+    for (int i = 0; i < 64; i++) b[i] = 2 * i + 1;
+  }
+  int ok = 1;
+  for (int i = 0; i < 64; i++) ok = ok && b[i] == 2 * i + 1;
+  printf("RESULT ran_on_host=%d check=%s\n", host_flag, ok ? "pass" : "fail");
+  return 0;
+}
+// site:
+// title: amdclang -fopenmp-version=60: error at(compilation) severity(warning) in a target region fails at the device link
+// + (__kmpc_error undefined)
+// control: ../vendor/checks/src/afar/control/afar-c-error-directive-in-target-link-control.c the error directive removed
+// end site

offload/_root/data/findings/afar-c-lastprivate-distribute-parallel-for-small-type.c

@@ -0,0 +1,56 @@
+/* # Finding (lead 2): AFAR amdclang returns 0 or a garbage value for a lastprivate item
+   # of fewer than 8 bytes on target teams distribute parallel for (C)
+
+   - compiler: AFAR amdclang 24.0.0git (drop 24.3.0), -fopenmp --offload-arch=gfx942 (MI300A,
+     HSA_XNACK 1 and 0) and gfx90a (MI250X, Tioga, XNACK 0), -fopenmp-version=52, -O2 and -O0
+   - expected: lp= 192 dev= 1. lastprivate gives the original lp the value of the sequentially
+     last iteration (i = 64: 3 * 64): "the value of each new list item from the sequentially last
+     iteration of the associated loops ... is assigned to the original list item" (5.2 §5.4.5
+     p.115 l.12-16); on the combined construct it applies to the distribute and for leaves (5.2
+     §17.2 p.340 l.21-22) and map(tofrom: lp) on the target leaf brings the value to the host.
+   - actual: MI300A (XNACK 1 and 0, -O2 and -O0): lp= 0 or a value that varies from run to run
+     (-1191462675, 948123843, 16246, ...; the trial saw 104571, 82972, 165175, 151912, 17038;
+     the review's 12 runs all printed 0);
+     MI250X: lp= 0 in every run. The same with short (14674, -18864, ...) and float (-1.1e-05, ...);
+     with target followed by teams distribute parallel for lastprivate(lp) inside it.
+   - same-compiler controls (each one change): long long lp or double lp gives 192 in every run
+     on both GPUs; target teams distribute lastprivate(lp) map(tofrom: lp) with the int gives 192;
+     target parallel for lastprivate(lp) map(tofrom: lp) with the int gives 192.
+   - no other family can witness: CCE craycc 19/20/21 give lp= -1 (the original unchanged) with
+     int and long long alike, their lastprivate defect on a for inside a target region
+     (cce-c-parallel-for-in-target.c); NVIDIA's guide documents lastprivate on distribute as
+     unsupported (HPC Compilers User's Guide 25.11, §7.4, 2.9.4), so nvc is no witness; AFAR
+     amdflang stops at "not yet implemented: lastprivate clause in constructs other than
+     simd/worksharing-loop/taskloop" on the Fortran form. The expected value rests on the spec
+     text and AFAR's own 8-byte and single-leaf controls.
+   - relation: stress/afar-c-lastprivate-combined-target-not-mapped.c is the missing implicit map
+     (no map clause: lp stays -1 with int and long long alike); this is a second defect, which is
+     why that finding's explicit-map control passes only with its long long item .
+   - legality: offload.engine.rules accepts it (with the race rule and the restriction checks:
+     offload.engine.prerun.check, rerun, data/evidence/lead_probe/logs/legality_new.jsonl), and nvc
+     26.9 and 25.11 (NVHPC, not under test for an AFAR finding) compile it with -mp=gpu
+     (data/evidence/lead_probe/logs/wingtip_witness.log); the check's other witness, the amdclang front
+     end, is AFAR's own and is not counted; no gfortran or gcc is a legality witness.
+     Race-free: lp is lastprivate; every iteration writes only its own copy.
+   - evidence: data/evidence/lead_probe/leads/ (lp_*.c), runs in data/evidence/lead_probe/logs/leads_*.jsonl;
+     reproduction (the gate's four environments by hand, as for
+     afar-c-teams-distribute-reduction-first-team.c): MI300A, XNACK 1 and 0, wrong in every run of
+     (a), (b), (c) and (d), but the value differs between runs (0, 16246, 337455926, -1176291223,
+     ...: the gate reads such a row as nondeterministic); MI250X (tioga39), (a), (b), (d): lp= 0 in
+     every run (confirmed). The long long control gave 192 in every environment. */
+#include <stdio.h>
+#include <omp.h>
+int main(void) {
+  int lp = -1;
+  int dev = -1;
+  #pragma omp target teams distribute parallel for lastprivate(lp) map(tofrom: lp)
+  for (int i = 1; i <= 64; i++)
+    lp = 3 * i;
+  #pragma omp target map(tofrom: dev)
+  dev = omp_is_initial_device() ? 0 : 1;
+  printf("lp= %d dev= %d\n", lp, dev);
+  return 0;
+}
+// site:
+// title: A lastprivate item smaller than 8 bytes on target teams distribute parallel for comes back as 0 or a garbage value
+// end site

offload/_root/data/findings/afar-c-teams-distribute-reduction-first-team.c

@@ -0,0 +1,59 @@
+/* # Finding (lead 1): AFAR amdclang keeps only the first team's partial result of a
+   # reduction on target teams distribute (C, -O1 and above)
+
+   - compiler: AFAR amdclang 24.0.0git (drop 24.3.0), -fopenmp --offload-arch=gfx942 (MI300A,
+     HSA_XNACK 1 and 0) and gfx90a (MI250X, Tioga, XNACK 0), -fopenmp-version=52, -O2
+   - expected: l= 83200 dev= 1 (the sum of 40 * i over i = 1..64). The reduction clause applies to
+     the teams leaf (5.2 §17.2 p.340 l.36-37, §5.5.8 p.134 l.18: distribute takes no reduction),
+     "For each list item, a private copy is created for each implicit task or SIMD lane and is
+     initialized with the initializer value of the reduction-identifier. After the end of the
+     region, the original list item is updated with the values of the private copies using the
+     combiner associated with the reduction-identifier" (5.2 §5.5.8 p.134 l.21-24)
+   - actual: l= 40 dev= 1: the region ran on the device and the original got only the first
+     team's partial sum (team 0 ran iteration 1). Every run at -O1, -O2 and -O3, MI300A at XNACK 1
+     and 0 and MI250X; with 1000 iterations l= 61600 (team 0's chunk) instead of 20020000. The
+     same with reduction(max: l) and the body l = max(l, i * 40) (l= 40, expected 2560; this is the
+     control of the HPE packet's cce-c-distribute-lastprivate-lost report that AFAR failed,
+     data/vendor/errata-for-findings.md item 23), with reduction(min: l) (l= 0, expected 40), with
+     double and int items, with num_teams(64), with target followed by teams distribute, and with
+     target teams reduction(+: l) around a distribute.
+   - same-compiler controls (each one change): the same file at -O0 gives l= 83200;
+     num_teams(8) or num_teams(4) or num_teams(1) gives 83200 (2560 for the max form);
+     target teams distribute parallel for reduction(max: l) gives 2560; AFAR amdflang's
+     target teams distribute reduction(max: l) over the same loop gives 2560.
+   - other families: CCE craycc 19.0.0, 20.0.2, 21.0.3 and 21.0.4 give l= 83200 on this file (and
+     2560, 20020000 on the max and 1000-iteration forms).
+   - legality: offload.engine.rules accepts it (with the race rule and the restriction checks:
+     offload.engine.prerun.check, rerun, data/evidence/lead_probe/logs/legality_new.jsonl), and nvc
+     26.9 and 25.11 (NVHPC, not under test for an AFAR finding) compile it with -mp=gpu
+     (data/evidence/lead_probe/logs/wingtip_witness.log); the check's other witness, the amdclang front
+     end, is AFAR's own and is not counted; no gfortran or gcc is a legality witness.
+     Race-free: each team updates only its private copy of l.
+   - evidence: data/evidence/lead_probe/leads/ (red_*.c, red3_*.c; jobs.py, run_leads.sh), runs in
+     data/evidence/lead_probe/logs/leads_*.jsonl
+   - reproduction (the gate's four environments by hand: data/evidence/lead_probe/confirm_jobs.py,
+     run_confirm.sh; logs/confirm_*.jsonl): MI300A, XNACK 1 and 0, (a) harness_<8 hex> and (d) a
+     second run there and (b) GATE + 14 letters on tuolumne1047, (c) the path of (a) on
+     tuolumne1042: l= 40 in every run (confirmed); MI250X (tioga39), (a), (b), (d): l= 40. The -O0
+     and num_teams(8) controls gave 83200 in every environment; CCE 19/20/21/21.0.4 gave 83200.
+   - upstream: llvm-project fixed it in 2c1650555b10 "[OpenMP][offload] Fix
+     single-thread SPMD cross-team reductions (#231843)" (2026-10-14, after the AFAR drop), with the
+     test offload/test/offloading/xteam_reduction_no_parallel.c; AFAR fails that test (gfx942 at
+     XNACK 0 and 1, gfx90a; gate confirmed), CCE 19/20/21 and NVHPC 25.11/26.9 pass it
+. */
+#include <stdio.h>
+#include <omp.h>
+int main(void) {
+  long long l = 0;
+  int dev = -1;
+  #pragma omp target teams distribute reduction(+: l) map(tofrom: l)
+  for (int i = 1; i <= 64; i++)
+    l += (long long) i * 40;
+  #pragma omp target map(tofrom: dev)
+  dev = omp_is_initial_device() ? 0 : 1;
+  printf("l= %lld dev= %d\n", l, dev);
+  return 0;
+}
+// site:
+// title: amdclang keeps only the first team's partial result of a reduction on target teams distribute
+// end site

offload/_root/data/findings/afar-c-update-iterator-copy-mode.c

@@ -0,0 +1,45 @@
+// (copy mode for the whole catalog): AFAR amdclang moves no data
+// for a target update motion clause with an iterator modifier, at
+// HSA_XNACK=0 (separate host and device memory).
+// The iterator k = 0:1 has the one value 0 (5.2 §3.2.6 p.67: i0 = begin,
+// i0 < end), so to(iterator(k = 0:1): a[k:n - k]) is to(a[0:n]): the
+// target update makes the device copy of a consistent with the host
+// (5.2 §13.9 p.289). Expected: to iterator: bad= 0 (from_iter: the same
+// with from(iterator(k = 0:1): b[k:n - k]) after a device write).
+// Observed (tuolumne, MI300A, 2026-10-22, 3 runs each, -O2,
+// OMP_TARGET_OFFLOAD=mandatory):
+// - AFAR amdclang 24.0.0git at HSA_XNACK=0: to iterator: bad= 64 (and
+//   from iterator: bad= 64): nothing is copied; the same update without
+//   the iterator, to(a[0:n]), gives bad= 0. Correct at HSA_XNACK=1 (one
+//   copy of the data).
+// - CCE craycc 19, 20, 21: reject the iterator modifier of to/from (the
+//   catalog's to.iterator and from.iterator C programs: "call to
+//   undeclared function").
+// The catalog's C to.iterator and from.iterator programs (5.2, 6.0) fail
+// on AFAR at HSA_XNACK=0 because of it, and so does the C map.iterator
+// program: target enter data map(iterator(k = 1:2), to: w[k:n / 2 - k])
+// (one value, the section w[1:31]) leaves w[1] not present in copy mode. AFAR amdflang rejects the Fortran
+// form ("not yet implemented").
+// AFAR: amdclang -fopenmp --offload-arch=gfx942 -fopenmp-version=52 -O2
+// Run:  OMP_TARGET_OFFLOAD=mandatory HSA_XNACK=0 ./a.out
+#include <stdio.h>
+enum { n = 64 };
+int main(void) {
+  int a[n], b[n], k, bad = 0;
+  for (int i = 0; i < n; i++) { a[i] = i; b[i] = 0; }
+  #pragma omp target enter data map(to: a) map(alloc: b)
+  for (int i = 0; i < n; i++) a[i] += 10;
+  #pragma omp target update to(iterator(k = 0:1): a[k:n - k])
+  #pragma omp target map(alloc: a, b)
+  for (int i = 0; i < n; i++) b[i] = a[i];
+  #pragma omp target update from(b)
+  #pragma omp target exit data map(release: a, b)
+  for (int i = 0; i < n; i++) bad += b[i] != i + 10;
+  printf("to iterator: bad= %d\n", bad);
+  return 0;
+}
+// site:
+// title: amdclang at HSA_XNACK=0: target update with an iterator modifier moves no data
+// control: ../vendor/checks/src/afar/control/afar-c-update-iterator-copy-mode-control.c to(a[0:n]) instead of to(iterator(k = 0:1):
+// + a[k:n - k])
+// end site

offload/_root/data/findings/afar-c-xnack1-target-is-present.c

@@ -0,0 +1,31 @@
+// The C form of afar-xnack1-target-is-present.f90.
+// After target enter data map(to: a), omp_target_is_present must return
+// true (5.2 §18.8.3 p.389; the enter data creates a corresponding storage
+// block, which may share storage with the original, 5.2 §5.8.3 p.153).
+// Expected: after enter data: present= 1, after exit data: present= 0
+// Observed (tuolumne, MI300A, 2026-10-22, 3 runs each, -O2,
+// OMP_TARGET_OFFLOAD=mandatory):
+// - AFAR amdclang 24.0.0git at HSA_XNACK=1: present= 0 after enter data;
+//   at HSA_XNACK=0: present= 1.
+// - CCE craycc 19.0.0: present= 1 / 0 in both modes.
+// AFAR: amdclang -fopenmp --offload-arch=gfx942 -fopenmp-version=52 -O2
+// CCE:  craycc -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa
+//       -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx942 -fopenmp-version=52 -O2
+// Run:  OMP_TARGET_OFFLOAD=mandatory HSA_XNACK=1 ./a.out
+#include <stdio.h>
+#include <omp.h>
+int main(void) {
+  int a[64], d = omp_get_default_device();
+  for (int i = 0; i < 64; i++) a[i] = 1;
+  #pragma omp target enter data map(to: a)
+  printf("after enter data: present= %d\n", omp_target_is_present(a, d));
+  #pragma omp target exit data map(release: a)
+  printf("after exit data: present= %d\n", omp_target_is_present(a, d));
+  return 0;
+}
+// site:
+// title: AFAR offload runtime at HSA_XNACK=1: omp_target_is_present returns false after target enter data, and map(present) of an
+// + absent item does not terminate
+// control: ../vendor/checks/src/afar/control/afar-c-xnack1-target-is-present-control.c run at HSA_XNACK=0
+// same_as: afar-xnack1-target-is-present
+// end site

offload/_root/data/findings/afar-cce19-character-defaultmap.f90

@@ -0,0 +1,27 @@
+program p
+  implicit none
+  character :: ch
+  character(len=4) :: s
+  integer :: k
+  ch = 'a'; s = 'abcd'; k = 1
+  !$omp target
+  ch = 'b'; s = 'wxyz'; k = 2
+  !$omp end target
+  print '(a,a,a,a,a,i0)', 'ch=', ch, ' s=', s, ' k=', k
+end program
+! site:
+! title: amdflang: a Fortran character scalar referenced in a target region is treated as a firstprivate scalar (writes lost)
+! control: ../vendor/checks/src/afar/control/afar-cce19-character-defaultmap-control.f90 ch and s mapped explicitly: map(tofrom:
+! + ch, s)
+! end site
+! spec (requirement): In Fortran a character variable is not a scalar variable for OpenMP: the scalar variable
+!   definition excludes the character type.
+! "For Fortran, a scalar variable with intrinsic type, as defined by the base language, excluding character type."
+!   (5.2 §1.2.6 p.14 l.7-8)
+! spec (requirement): A variable referenced in a target construct that is not a scalar is implicitly mapped with
+!   map-type tofrom, so a character variable is mapped and its modification is visible after the region.
+! "If a variable is not a scalar then it is treated as if it had appeared in a map clause with a map-type of tofrom."
+!   (5.2 §5.8.1 p.149 l.4-5)
+! spec (this program): ch and s are character variables referenced in the target region with no map or defaultmap
+!   clause, so both are implicitly mapped tofrom and come back as b and wxyz; amdflang treats them as firstprivate
+!   scalars and the writes are lost (k, an integer scalar, is firstprivate and keeps its value).

offload/_root/data/findings/afar-cce19-task-in-target-ice.f90

@@ -0,0 +1,23 @@
+program t
+  implicit none
+  integer :: c, r
+  r = 0
+  !$omp target map(from: r)
+    c = 7
+    !$omp task default(shared)
+      c = 42
+    !$omp end task
+    !$omp taskwait
+    r = c
+  !$omp end target
+  print *, 'r=', r
+end program
+! site:
+! title: ftn/craycc: constructs documented as unsupported in offload regions (single, masked, task, ordered, scan) give internal
+! + compiler errors or device link failures instead of a diagnostic
+! control: ../vendor/checks/src/afar/control/afar-cce19-task-in-target-ice-control.f90 the task and taskwait constructs removed
+! + (the task
+! + body
+! + kept)
+! same_as: cce19-target-parallel-single-ice
+! end site

offload/_root/data/findings/afar-clang-requires-device-safesync-hang.c

@@ -0,0 +1,24 @@
+/* Finding (C): AFAR amdclang hangs on requires device_safesync.
+
+   Legal OpenMP 6.0 C (6.0 §10.5.1.7: device_safesync is a requires
+   clause; without an argument it means device_safesync(true)).
+
+   Observed (2026-10-19): amdclang (AFAR 24.0.0git, drop 24.3.0) does not
+   finish on this file: killed after 90 s with
+   `-fopenmp -fopenmp-version=60 --offload-arch=gfx942 -c`, after 300 s
+   with `-fopenmp -fopenmp-version=60 -fsyntax-only`, and after 30 s with
+   `-fopenmp-version=52 -fsyntax-only` (where the clause is unknown and
+   should be diagnosed). The omp60-c-clause-device_safesync programs time
+   out in compilation. CCE craycc 19.0.0, 20.0.2 and 21.0.3 stop at once:
+   "warning: extra tokens at the end of '#pragma omp requires' are
+   ignored" and "error: expected at least one clause on '#pragma omp
+   requires' directive" (the clause is unknown to them). AFAR amdflang
+   compiles and runs the Fortran form (`!$omp requires device_safesync`;
+   omp60-clause-device_safesync: unobservable). */
+#pragma omp requires device_safesync
+int main(void) { return 0; }
+// site:
+// title: amdclang -fopenmp-version=60: compile does not finish on #pragma omp requires device_safesync
+// control: ../vendor/checks/src/afar/control/afar-clang-requires-device-safesync-hang-control.c another requires clause,
+// + atomic_default_mem_order(seq_cst)
+// end site

offload/_root/data/findings/afar-flang-firstprivate-map-two-targets.f90

@@ -0,0 +1,34 @@
+program p
+  implicit none
+  integer :: a(10), i, p1
+  p1 = 3
+  !$omp target firstprivate(p1) map(from: a)
+    do i = 1, 10
+      a(i) = p1
+    end do
+  !$omp end target
+  !$omp target map(to: p1) map(tofrom: a)
+    do i = 1, 10
+      a(i) = a(i) + p1
+    end do
+  !$omp end target
+  print *, 'a(3) =', a(3)
+end program p
+! site:
+! title: amdflang: firstprivate(p1) on one target and map(to: p1) on a later target rejected as if on the same construct
+! control: ../vendor/checks/src/afar/control/afar-flang-firstprivate-map-two-targets-control.f90 map(to: p1) instead of
+! + firstprivate(p1)
+! + on the
+! + first target
+! end site
+! spec (requirement): The data environment of each target task is created from the data-sharing and data-mapping
+!   clauses on that one target construct, so clauses on different target constructs do not interact.
+! "The data environment of the target task is created according to the data-sharing and data-mapping attribute clauses
+!   on the target construct" (5.2 §13.8 p.284 l.19-21)
+! spec (requirement): A firstprivate list item on a target construct is initialized from the original list item that
+!   exists before that construct.
+! "In addition, the new list item is initialized from the original list item that exists before the construct." (5.2
+!   §5.4.4 p.112 l.11-12)
+! spec (this program): p1 is firstprivate on the first target construct and appears in map(to:) only on the second,
+!   separate target construct, so no list item has two attributes on one construct; amdflang rejects the second target
+!   as if both clauses were on the same construct.

offload/_root/data/findings/afar-flang-loop-bind-teams-reduction.f90

@@ -0,0 +1,27 @@
+program p
+  implicit none
+  integer :: r, i
+  r = 0
+  !$omp target teams map(tofrom: r)
+    !$omp loop bind(teams) reduction(+: r)
+    do i = 1, 10
+      r = r + i
+    end do
+  !$omp end target teams
+  print *, 'r =', r
+end program p
+! site:
+! title: amdflang: reduction on loop bind(teams) nested in a target teams region rejected
+! control: ../vendor/checks/src/afar/control/afar-flang-loop-bind-teams-reduction-control.f90 bind(teams) removed (the loop binds
+! + to the
+! + teams
+! + region by default)
+! end site
+! spec (requirement): The reduction clause is permitted on the loop construct.
+! "bind, collapse, lastprivate, order, private, reduction" (5.2 §11.7 p.257 l.4)
+! spec (requirement): The behavior of a reduction clause on a loop with bind(teams) is unspecified only when the loop
+!   is not nested inside a teams construct (and executes on a non-host device); nested inside teams it is specified.
+! "then the behavior of a reduction clause that appears on the corresponding loop construct is unspecified if the
+!   construct is not nested inside a teams construct." (5.2 §11.7.1 p.259 l.5-7)
+! spec (this program): The loop bind(teams) reduction(+: r) is strictly nested in the teams region of target teams,
+!   the case the restriction leaves specified, so r must be 55; amdflang rejects the reduction.

offload/_root/data/findings/afar-flang-task-reduction-max.f90

@@ -0,0 +1,31 @@
+program p
+  implicit none
+  integer :: r, i
+  r = 0
+  !$omp taskgroup task_reduction(max: r)
+    !$omp target in_reduction(max: r)
+      do i = 1, 10
+        r = max(r, i)
+      end do
+    !$omp end target
+  !$omp end taskgroup
+  print *, 'r =', r
+end program p
+! site:
+! title: amdflang: task_reduction(max: r) / in_reduction(max: r) rejected ("Internal: no symbol found for 'max'")
+! control: ../vendor/checks/src/afar/control/afar-flang-task-reduction-max-control.f90 the reduction identifier + instead of max
+! + (r = r + i)
+! end site
+! spec (requirement): In Fortran the intrinsic procedure names max and min are OpenMP reduction identifiers, usable
+!   wherever a reduction identifier is.
+! "following intrinsic procedure names: max, min, iand, ior, ieor." (5.2 §5.5.1 p.124 l.24)
+! spec (requirement): The task_reduction clause on a taskgroup specifies a reduction among tasks.
+! "The task_reduction clause is a reduction scoping clause, as described in Section 5.5.6, that specifies a reduction
+!   among tasks." (5.2 §5.5.9 p.137 l.14-15)
+! spec (requirement): An in_reduction clause makes a task a participant in a task reduction defined by an enclosing
+!   task_reduction clause with the same reduction identifier.
+! "defines a task to be a participant in a task reduction that is defined by an enclosing region for a matching list
+!   item that appears in a task_reduction clause" (5.2 §5.5.10 p.138 l.11-13)
+! spec (this program): task_reduction(max: r) on a taskgroup and in_reduction(max: r) on the enclosed target use the
+!   intrinsic max as reduction identifier for an integer; amdflang rejects both clauses with Internal: no symbol found
+!   for max.

offload/_root/data/findings/afar-flang-thread-limit-target-parallel-do.f90

@@ -0,0 +1,22 @@
+program p
+  implicit none
+  integer :: a(10), i
+  a = 0
+  !$omp target parallel do thread_limit(8) map(from: a)
+  do i = 1, 10
+    a(i) = i
+  end do
+  print *, 'a(3) =', a(3)
+end program p
+! site:
+! title: amdflang: thread_limit on target parallel do rejected
+! control: ../vendor/checks/src/afar/control/afar-flang-thread-limit-target-parallel-do-control.f90 thread_limit(8) removed
+! end site
+! spec (requirement): The thread_limit clause is permitted on the target construct.
+! "in_reduction, is_device_ptr, map, nowait, private, thread_limit," (5.2 §13.8 p.284 l.5)
+! spec (requirement): On a combined construct the thread_limit clause applies to every leaf construct that permits it,
+!   so it is accepted on target parallel do and takes effect on the target leaf.
+! "The effect of the shared, default, thread_limit, or order clause is as if it is applied to all leaf constructs that
+!   permit the clause." (5.2 §17.2 p.340 l.31-32)
+! spec (this program): thread_limit(8) on target parallel do is applied to the target leaf construct, which permits
+!   the clause; amdflang rejects the clause on the combined construct.

offload/_root/data/findings/afar-linear-ref-omp50.f90

@@ -0,0 +1,29 @@
+! OpenMP 5.0: linear(ref(x)) on declare simd with x a scalar dummy argument.
+! 5.0 §2.19.4.6 p.293: "The ref or uval modifier can only be used if the
+! list-item is a dummy argument without the VALUE attribute." and "If the
+! ref modifier is specified, variables with the ALLOCATABLE attribute,
+! assumed-shape arrays and polymorphic variables may not appear in the
+! linear clause." -- so a scalar dummy is the legal 5.0 form.
+! (5.2 §5.4.6 p.119 reverses this: with ref the item must be polymorphic,
+! assumed-shape or ALLOCATABLE.) Expected with -fopenmp-version=50: accepted.
+module m
+contains
+  integer function lf(x)
+    !$omp declare simd(lf) linear(ref(x))
+    integer, intent(in) :: x
+    lf = 2*x + 1
+  end function lf
+end module m
+program p
+  use m
+  implicit none
+  integer :: i, b(4)
+  do i = 1, 4
+    b(i) = lf(i)
+  end do
+  print *, b
+end program p
+! site:
+! disposition: out-of-scope host-only construct (declare simd on a host procedure, no target region): outside the device-offload
+! + scope; the README does not mark it out of scope
+! end site

offload/_root/data/findings/afar-loop-bind-thread-in-teams.f90

@@ -0,0 +1,44 @@
+! loop bind(thread) closely nested in teams (README.md). Expected: tot= 64 64 64 64,
+! which CCE prints as `tot= 4*64` (a list-directed repeat count: the same values,
+! a correction). Each team's mine is private (teams private(tm, mine)) and the loop's
+! binding thread set is the encountering thread, so no race (offload.engine.prerun's race rule
+! flags mine: a false positive).
+program t
+  use omp_lib, only: omp_get_team_num
+  implicit none
+  integer, parameter :: n = 64
+  integer :: tot(4), tm, mine, i
+  tot = 0
+  !$omp target map(tofrom: tot)
+    !$omp teams num_teams(4) private(tm, mine)
+      tm = omp_get_team_num()
+      mine = 0
+      !$omp loop bind(thread)
+        do i = 1, n
+          mine = mine + 1
+        end do
+      !$omp end loop
+      tot(tm + 1) = mine
+    !$omp end teams
+  !$omp end target
+  print *, 'tot=', tot
+end program
+! site:
+! title: amdflang: loop bind(thread) closely nested in teams rejected ("BIND(TEAMS) must be specified")
+! control: ../vendor/checks/src/afar/control/afar-loop-bind-thread-in-teams-control.f90 the loop directive removed (a plain DO
+! + loop in
+! + each team)
+! end site
+! spec (requirement): With bind(thread) the binding region of a loop construct is not defined.
+! "if binding is thread then the binding region is not defined" (5.2 §11.7.1 p.258 l.24-25)
+! spec (requirement): When the binding region is not defined, the binding thread set is the encountering thread, so
+!   each thread executes all iterations of the loop it encounters.
+! "If the binding region is not defined, then the binding thread set is the encountering thread." (5.2 §11.7.1 p.258
+!   l.31-32)
+! spec (requirement): The bind clause is required only when the loop construct is not nested inside another OpenMP
+!   construct.
+! "If a loop construct is not nested inside another OpenMP construct then the bind clause must be present." (5.2 §11.7
+!   p.258 l.1-2)
+! spec (this program): The loop bind(thread) is closely nested in teams, so each team's initial thread runs all 64
+!   iterations on its private mine and tot is 64 for every team; amdflang rejects the construct with BIND(TEAMS) must
+!   be specified.

offload/_root/data/findings/afar-nontemporal-assumed-shape-ice.f90

@@ -0,0 +1,38 @@
+program p
+  implicit none
+  integer, parameter :: n = 16, m = 4
+  integer :: o1(n, m), i, j
+  integer(8) :: cs
+  o1 = 0
+  call kp(o1)
+  cs = sum(int(o1, 8))
+  print '(a,i0,a,i0)', 'RESULT checksum=', cs, ' ran_on_host=', 0
+contains
+  subroutine kp(o1)
+    integer, intent(inout) :: o1(:, :)
+    integer :: i, j
+    !$omp target teams distribute parallel do map(tofrom: o1)
+    do i = 1, n
+      !$omp simd nontemporal(o1)
+      do j = 1, m
+        o1(i, j) = i + j
+      end do
+    end do
+  end subroutine kp
+end program p
+! site:
+! title: amdflang: "verification of lowering to FIR failed" for nontemporal on an assumed-shape dummy
+! control: ../vendor/checks/src/afar/control/afar-nontemporal-assumed-shape-ice-control.f90 nontemporal(o1) removed from the simd
+! + directive
+! end site
+! spec (requirement): The nontemporal clause on a simd construct takes a list of variables, and its text states no
+!   restriction on their form, so an assumed-shape dummy array is a valid list item.
+! "The nontemporal clause specifies that accesses to the storage locations to which the list items refer have low
+!   temporal locality across the iterations in which those storage locations are accessed." (5.2 §10.4.1 p.236
+!   l.21-22)
+! spec (requirement): The list items of nontemporal may also appear in data-environment attribute clauses.
+! "The list items of the nontemporal clause may also appear as list items of data-environment attribute clauses." (5.2
+!   §10.4.1 p.236 l.23-24)
+! spec (this program): nontemporal(o1) names an assumed-shape dummy that is also mapped by the enclosing target
+!   construct; the spec text has no restriction against assumed-shape list items (it does not mention them), and
+!   amdflang stops with a failed lowering to FIR.

offload/_root/data/findings/afar-udr-derived-type-link.f90

@@ -0,0 +1,41 @@
+module fuzz_dmod
+  implicit none
+  type :: pair_t
+    integer :: x, y
+  end type pair_t
+  !$omp declare reduction(padd: pair_t: omp_out = &
+  !$omp& pair_t(omp_out%x + omp_in%x, omp_out%y + omp_in%y)) &
+  !$omp& initializer(omp_priv = pair_t(0, 0))
+end module fuzz_dmod
+program fuzz_prog
+  use fuzz_dmod
+  implicit none
+  integer, parameter :: n = 64
+  type(pair_t) :: rp
+  integer :: i
+  rp = pair_t(1, 2)
+  !$omp target teams distribute parallel do reduction(padd: rp) map(tofrom: rp)
+  do i = 1, n
+    rp = pair_t(rp%x + i, rp%y + mod(i, 3))
+  end do
+  print '(a,i0,a,i0)', 'RESULT checksum=', rp%x * 1000 + rp%y, ' ran_on_host=', 0
+end program fuzz_prog
+! site:
+! title: amdflang: declare reduction on a derived type used in a target loop fails at the device link (flang runtime symbols
+! + undefined)
+! control: ../vendor/checks/src/afar/control/afar-udr-derived-type-link-control.f90 the same reduction on a host parallel do (no
+! + target
+! + teams
+! + distribute)
+! end site
+! spec (requirement): A declare reduction directive declares a user-defined reduction identifier usable in a reduction
+!   clause.
+! "The declare reduction directive declares a reduction-identifier that can be used in a reduction clause as a
+!   user-defined reduction." (5.2 §5.5.11 p.139 l.18-19)
+! spec (requirement): The identifier can be used in a reduction clause on variables of the types listed in the
+!   directive, here a derived type.
+! "The reduction-identifier can later be used in a reduction clause that uses variables of the types specified in the
+!   declare reduction directive." (5.2 §5.5.11 p.139 l.24-26)
+! spec (this program): The module declares reduction(padd: pair_t) and the program uses padd on a target teams
+!   distribute parallel do; the compiler must generate the combiner and initializer for the device, and amdflang
+!   instead fails at the device link on undefined flang runtime symbols.

offload/_root/data/findings/afar-xnack1-atomic-min-nested-parallel.f90

@@ -0,0 +1,53 @@
+! AFAR (amdflang 24.0.0git, drop 24.3.0), MI300A gfx942, -O2:
+! an `atomic` min update of a mapped scalar inside a `parallel do` nested in
+! `target teams distribute`, with an allocatable array written in the same
+! loop, faults at HSA_XNACK=1 ("memory access fault ... Write access to a
+! read-only page"); at HSA_XNACK=0 it prints r=0 s=0 (correct).
+! Needed: an array written in the loop, the inner parallel do (without it: correct), and an
+! atomic update whose right-hand side depends on i. An atomic add with a constant right-hand
+! side is correct; r = r + mod(i, n) faults like the atomic min. In this combined form the
+! allocatable o1 faults and an explicit-shape array is correct; with separate directives the
+! explicit-shape array faults too (18-program matrix: data/reports/fuzz5-oop-afar.md, cluster C).
+! map(always) or an explicit map of o1 do not matter.
+! Hand-reduced from data/findings/fuzz/b2-183-afar.f90.
+!   amdflang -fopenmp --offload-arch=gfx942 -O2 afar-xnack1-atomic-min-nested-parallel.f90
+!   HSA_XNACK=1 OMP_TARGET_OFFLOAD=mandatory ./a.out
+program p
+  implicit none
+  integer, parameter :: n = 24, m = 2
+  integer, allocatable :: o1(:,:)
+  integer :: i, j, r
+  allocate(o1(n, m))
+  o1 = 0
+  r = 7
+  !$omp target teams distribute map(tofrom: r)
+  do i = 1, n
+    !$omp parallel do
+    do j = 1, m
+      o1(i, j) = 0
+      !$omp atomic
+      r = min(r, mod(i, n))
+    end do
+    !$omp end parallel do
+  end do
+  !$omp end target teams distribute
+  print '(a,i0,a,i0)', 'r=', r, ' s=', sum(o1)
+end program p
+! site:
+! title: amdflang at HSA_XNACK=1: atomic min in a parallel do nested in target teams distribute with an allocatable array faults
+! + (write to a read-only page)
+! control: ../vendor/checks/src/afar/control/afar-xnack1-atomic-min-nested-parallel-control.f90 o1 an explicit-shape array
+! + instead of an
+! + allocatable
+! end site
+! spec (requirement): In Fortran an atomic update may have the form x = intrinsic-procedure-name(x, expr-list) where
+!   the intrinsic is MAX or MIN.
+! "x = intrinsic-procedure-name (x, expr-list)" (5.2 §4.3.1.3 p.81 l.14)
+! spec (requirement): The atomic construct makes the access to the storage location atomic, so concurrent updates by
+!   the threads of nested parallel regions produce no indeterminate value.
+! "The atomic construct ensures that a specific storage location is accessed atomically so that possible simultaneous
+!   reads and writes by multiple threads do not result in indeterminate values." (5.2 §15.8.4 p.311 l.29-30)
+! spec (this program): The atomic min update of the mapped scalar r runs in a parallel do nested in target teams
+!   distribute and must give r = 0; the spec has no text on memory faults with unified-memory settings (HSA_XNACK=1 is
+!   a vendor runtime setting), so the cited text states only that the update must complete correctly, and the write
+!   access fault to a read-only page is a deviation from it.