offtarget 0.1.0__py3-none-any.whl

offload/_root/data/findings/stress/cce-c-distribute-lastprivate-lost.c

@@ -0,0 +1,52 @@
+/* # Finding: CCE craycc loses lastprivate on a distribute construct in a
+   # target region, even with an explicit map (C)
+
+   - compilers: CCE craycc 19.0.0, 20.0.2, 21.0.3, MI300A (gfx942), HSA_XNACK 1 and 0, -O2
+   - expected: l= 2560 dev= 1. lastprivate on distribute gives the original l the value of the
+     sequentially last iteration (i = 64: 64 * 40) (5.2 §5.4.5; §11.6 distribute accepts
+     lastprivate); map(tofrom: l) on the target leaf (§17.2 p.340 l.21-30 applies lastprivate to
+     the distribute leaf and map to the target leaf) brings it back
+   - actual: l= 0 dev= 1 on all three releases and both XNACK settings, in both forms:
+       this file               target teams distribute lastprivate(l) map(tofrom: l)
+       lp-c-tdist-split.c      target map(tofrom: l, dev) { teams distribute lastprivate(l) }
+     (data/reports/fuzz-stress-audit/; the audit saw the first form fail on CCE 19 and 21)
+   - in-program control (lp-c-tdist-split.c): dev is mapped tofrom in the same map clause as l and
+     written inside the same distribute loop (at i = 1); it comes back as 1 while l comes back as 0,
+     which rules out "a scalar map in a distribute region" as the cause
+   - same-compiler control: lp-c-tdist-copy.c, the same target teams distribute loop without
+     lastprivate, where the last iteration stores its value in a mapped array: l= 2560 on CCE
+     19/20/21, both XNACK settings. A reduction(max: l) on target teams distribute parallel for
+     (lp-c-tdpf-red.c) gives 2560 too
+   - other families: AFAR amdclang (both forms, both XNACK settings) and NVHPC nvc 25.11 / 26.9
+     (A100, separate and managed) give 2560 on both forms
+   - not the known finding: cce-c-parallel-for-in-target.c covers lastprivate on a parallel for
+     nested in a target region (CCE also gives 0 on target parallel for lastprivate(l)
+     map(tofrom: l), lp-c-tpfor-map.c, which that finding explains). This program has no parallel
+     for: the loss is on distribute. On target teams distribute parallel for (candidate 2b,
+     r2-lastprivate-combined-control.c) both leaves carry lastprivate, so both defects apply
+   - legality: legal by reading: the loop variable is private; only the lastprivate item l is
+     written in the loop; dev is written by the initial thread of the second target region. The
+     explicit map is legal: 5.2 §13.8 p.286 l.29-30 restricts only data-sharing clauses applied to
+     the target leaf, and the 5.0 §2.19.7.1 restriction (p.321 l.25-26) exempts combined constructs
+   - evidence: results/stress/audit/runs-fix2.jsonl (tools/jobs/run_stress_fix2.sh a) and
+     runs-nvhpc-fix2.jsonl (tools/jobs/run_wingtip_fix2.sh); the confirmer was not run on it
+   - build: craycc -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa
+     -march=gfx942 -O2 (offload/engine/toolchains.py C_FLAGS); the program is the audit file as run
+     (out[] is unused here) */
+#include <stdio.h>
+#include <omp.h>
+int main(void) {
+  long long l = 0, out[1] = {0};
+  int dev = -1;
+  #pragma omp target teams distribute lastprivate(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: craycc/ftn: lastprivate on distribute in a target region loses the final value, even with an explicit map
+// control: ../vendor/checks/src/cce/control/cce-c-distribute-lastprivate-lost-control.c reduction(max: l) instead of lastprivate(l)
+// end site

offload/_root/data/findings/stress/cce-c-flto-offload-dropped.c

@@ -0,0 +1,73 @@
+// # Finding: craycc -flto drops the OpenMP offload code
+//
+// - compilers: CCE craycc 19.0.0, 20.0.2, 21.0.3 (C), MI300A (gfx942) and MI250X (gfx90a)
+// - build: the catalog's CCE C recipe (offload/engine/toolchains.py C_FLAGS) plus `-O2 -flto`;
+//   without -flto the same file is correct on every CCE release; AFAR amdclang -flto is correct
+// - expected: sum= 2016 dev= 1 (a target teams distribute loop fills a[i] = i on the device)
+// - build flags: -O2 -flto
+//   (read by the confirmer, offload.engine.confirm.programs.file_ref, which adds them to every
+//   build of this reproducer; its -O0 control keeps -flto)
+// - actual (OMP_TARGET_OFFLOAD=mandatory): the program builds, then exits 255 with "ACC: OpenMP
+//   offload failed when OMP_TARGET_OFFLOAD=MANDATORY at address 0x200a...". Observed cells:
+//   MI300A HSA_XNACK 1 (CCE 19/20/21, audit runs.jsonl), MI250X HSA_XNACK 0 (Tioga, CCE 19/20/21,
+//   runs-tioga.jsonl), and MI300A HSA_XNACK 0 (CCE 19 and 21; CCE 19/20/21,
+//   runs-fix2.jsonl). Under
+//   OMP_TARGET_OFFLOAD=default the -flto binary runs the region on the host: "sum= 2016 dev= 0".
+// - the offload code is absent (readelf/nm of the executables, CCE 19.0.0 and 21.0.3,
+//   MI300A): without -flto the binary has a cray_omp_offloading_entries section, the
+//   .offloading.entry.__omp_offloading_* symbols and 7 strings naming amdgcn/gfx942; with -O2 -flto
+//   the entries section and the entry symbols are gone (only the .region_id symbols remain) and no
+//   amdgcn/gfx942 string is left. AFAR amdclang -flto keeps .llvm.offloading and its entries and
+//   runs on the device. Not run: the non--flto control on MI250X.
+// - evidence: results/stress/audit/runs.jsonl and runs-tioga.jsonl (tools/campaigns/stress_audit.py on
+//   data/reports/fuzz-stress-audit/r8-craycc-flto.c); the audit rerun's runs are committed as
+//   data/reports/fuzz-stress-audit/rereview-1-lto.jsonl. In the stress sweeps every C program of
+//   the `lto` variant failed the same way (s1-var, 3 CCE releases x 3 layouts), and every other
+//   variant agreed
+// - confirmer (which carries the "build flags" line above into every build): on CCE 19 in
+//   both modes (`tools/confirm.py case <this file> --toolchain cce19 --mode unified|copy --expected
+//   "sum= 2016 dev= 1" --run`, 2026-10-25) the verdict is needs_human (R22-expected-weak): CCE 19, 20
+//   and 21 built with -O2 -flto exit 255 on every run and AFAR amdclang -O2 -flto prints the expected
+//   value, but the expected value rests on the stated value alone (no sequential elision of this C
+//   program), which the rules call provisional. Before the confirmer could not add -flto
+//   (data/reports/fuzz-stress.md). The installed CCE documentation has no craycc page
+//   and does not say that -flto is unsupported with offload; if HPE documents that, this is a
+//   documented limitation, not a defect.
+// - legality: legal C11 / OpenMP 5.0 by reading: a[0:64] is mapped from and each iteration writes
+//   its own element; dev is mapped tofrom and written by the one initial thread of a target region
+//   (amdclang -fopenmp -fsyntax-only, not of the family under test, accepts it)
+/* Audit: craycc -flto with OpenMP offload. A target teams
+   distribute loop; built with -flto it must still run on the device.
+   Expected (with and without -flto): sum= 2016 dev= 1 */
+#include <stdio.h>
+#include <omp.h>
+int main(void) {
+  long long a[64], sum = 0;
+  int dev = -1;
+  #pragma omp target teams distribute map(from: a[0:64])
+  for (int i = 0; i < 64; i++)
+    a[i] = i;
+  for (int i = 0; i < 64; i++)
+    sum += a[i];
+  #pragma omp target map(tofrom: dev)
+  dev = omp_is_initial_device() ? 0 : 1;
+  printf("sum= %lld dev= %d\n", sum, dev);
+  return 0;
+}
+// site:
+// title: craycc -flto: the offload code is dropped; the program fails under OMP_TARGET_OFFLOAD=mandatory
+// control: ../vendor/checks/src/cce/control/cce-c-flto-offload-dropped-control.c built without -flto (-O2)
+// end site
+// spec (requirement): a target construct includes an executable region that is executed on a device, and with
+//   OMP_TARGET_OFFLOAD=mandatory a construct that cannot use its device is an error instead of a host fallback. The -flto option
+//   is a vendor build option that OpenMP does not mention, so there is no OpenMP text on link-time optimization itself; the
+//   nearest normative text is the device execution of the target region.
+// "The target construct provides a superset of the functionality provided by the target data directive, except for the
+//   use_device_ptr and use_device_addr clauses. The functionality added to the target directive is the inclusion of an executable
+//   region to be executed on a device." (5.2 §13.8 p.284 l.11-13)
+// "The mandatory value specifies that the effect of any device construct or device memory routine that uses a device that is
+//   unavailable or not supported by the implementation, or uses a non-conforming device number, is as if the omp_invalid_device
+//   device number was used." (5.2 §21.2.8 p.610 l.28-30)
+// spec (this program): the target teams distribute region must still execute on the device in a program built with -flto; the
+//   binary has lost its offload entries, so OMP_TARGET_OFFLOAD=mandatory aborts (the default setting silently runs the region on
+//   the host, dev= 0).

offload/_root/data/findings/stress/cce-ftn-cif-record-split-abort.f90

@@ -0,0 +1,109 @@
+! # Finding: CCE ftn aborts when an optimizer message record has "-1" at its 1024th character
+!
+! - compilers: CCE ftn 17.0.1, 18.0.1, 19.0.0, 20.0.0, 20.0.2, 21.0.0, 21.0.3, 21.0.4, the same on
+!   Tuolumne (craype-accel-amd-gfx942) and Tioga (gfx90a), 2026-10-25; the defect is on the host side
+! - build: save this file as stress.f90 in the directory
+!     A = /tmp/cce-cif/ + 202 letters a + -1aa        (219 characters; one directory below /tmp/cce-cif)
+!   and run `ftn -fopenmp -O2 -c stress.f90` there (the pinned prelude: module load cce/<v>
+!   craype-accel-amd-gfx942 rocm/<r>; module unload cray-mpich). tools/jobs/run_ftn_cif_split.sh repro does it.
+! - expected: the compile succeeds (exit 0) and prints the program's 3 messages (ftn-878 warnings: glob is
+!   use associated twice in c2, c1 and the main program). Legal Fortran 2008 with OpenMP 5.0 directives,
+!   by reading: `!$omp declare target (extended-list)` (5.0 §2.12.7 p.181 l.15) gives gv a device copy
+!   ("initialized once ... never removed", p.182 l.19-22); `!$omp declare target` without clauses in a
+!   function makes that function a device procedure ("an implicit extended-list ... of one item is formed
+!   from the name of the enclosing ... function subprogram", p.183 l.21-23); `target update to(gv)`
+!   (§2.12.6); each iteration writes its own out(i). "An implementation of the OpenMP API is compliant if
+!   and only if it compiles and executes all other conforming programs" (5.0 §1.6 p.31 l.11-12). A run
+!   (not part of this finding) prints sum=145702.
+! - actual: every release above: SIGABRT (exit 6) with "free(): invalid pointer" (17.0.1: "double free or
+!   corruption (out)"), no messages, no object. Also at -O3 and when linking; not at -O0 (no optimizer
+!   messages). AFAR amdflang compiles the file in A (-fopenmp --offload-arch=gfx942 -O2 -c).
+! - control: the same file in the directory of the same length with -2aa in place of -1aa compiles on every
+!   release with its 3 messages (the check case's control,
+! + ../vendor/checks/src/cce/control/cce-ftn-cif-record-split-abort-control.f90).
+!   What matters is the absolute path of the source file: compiled from another working directory with the
+!   source named by its path in A it aborts; compiled in A with the source taken from another directory it
+!   does not; -o, -J, PWD and TMPDIR do not matter.
+! - mechanism (CCE 19.0.0 binaries, gdb, valgrind, strace): optcg's m_cif_merge_messages (and ftnfe's
+!   finish_msgs_and_cif) copy the compiler-information records into the CIF the driver prints messages
+!   from with `fgets(buf, 1024)` per chunk, stopping at the first chunk whose strtol value is -1 (the end
+!   record). IPA's message 'Tree "g2" was flattened.#"g2"(<path>/stress.f90:22)   "g3"(<path>/stress.f90:10)'
+!   carries the absolute source path, twice per record, so in A the record is longer than 1023 characters
+!   and its chunk at offset 1023 starts with "-1aa/stress.f90...": the copy stops there and the CIF is cut
+!   mid-record. The driver (Cif_Cifconv, write_unit) then calls free() on a pointer 984 bytes into a
+!   16 KiB block of its CIF arena (valgrind, the tu12 program: "Invalid free"), and glibc aborts.
+!   A cut in another record can instead give exit 0 with every later message silently dropped.
+! - the rule, verified on 1,749 compiles (CCE 19 for all; 20.0.2 and 21.0.3 for the tu12 set, identical):
+!   in every compile where some record line, with the path substituted, has "-1" not followed by a digit at
+!   offset 1023 (or 2046, ...), the compile aborted or printed fewer messages than the control; in every
+!   other compile it printed all of them; no abort without such a split (tools/campaigns/ftn_cif_split.py,
+!   data/reports/fuzz-stress-audit/ftnpath/). Whether a cut aborts depends on where the CIF is cut (here: in
+!   g2's flattening record, 42 of 42 designed directories of 219-260 characters abort).
+! - origin: the stress campaign's "path-dependent" ftn abort (data/reports/fuzz-stress.md F2): tu.plain-omp-12
+!   in /tmp/<user>-stress/st-tu.plain-omp-12-1-abcd1234 has "12-1-abcd" in its directory name, and IPA's
+!   message for k0001_g7 puts that "-1" at offset 1023 (data/reports/fuzz-stress-audit/ftn-path-abort-tu12.f90)
+module glob
+  implicit none
+  integer(8) :: gv = 0
+  !$omp declare target(gv)
+end module glob
+module c3
+  use glob
+  implicit none
+contains
+  function g3(x) result(r)
+    !$omp declare target
+    integer(8), intent(in) :: x
+    integer(8) :: r
+    r = x + gv
+  end function g3
+end module c3
+module c2
+  use glob
+  use c3
+  implicit none
+contains
+  function g2(x) result(r)
+    !$omp declare target
+    integer(8), intent(in) :: x
+    integer(8) :: r
+    r = g3(mod(x * 5, 1013_8) + 2) + 2
+  end function g2
+end module c2
+module c1
+  use glob
+  use c2
+  implicit none
+contains
+  function g1(x) result(r)
+    !$omp declare target
+    integer(8), intent(in) :: x
+    integer(8) :: r
+    r = g2(mod(x * 5, 1013_8) + 1) + 1
+  end function g1
+end module c1
+program chain
+  use glob
+  use c1
+  implicit none
+  integer(8) :: out(256), s
+  integer :: i
+  gv = 77
+  !$omp target update to(gv)
+  out = 0
+  !$omp target teams distribute parallel do map(tofrom: out)
+  do i = 1, 256
+    out(i) = g1(int(i, 8))
+  end do
+  !$omp end target teams distribute parallel do
+  s = sum(out)
+  print '(a,i0)', 'sum=', s
+end program chain
+! site:
+! title: ftn: compiler aborts (free(): invalid pointer) when an optimizer message record has "-1" at its 1024th character
+! + (path-dependent)
+! control: ../vendor/checks/src/cce/control/cce-ftn-cif-record-split-abort-control.f90 the same file in a directory of the same
+! + length
+! + with -2
+! + in place of -1
+! end site

offload/_root/data/findings/stress/cce-lastprivate-num-threads-collapse-simd.f90

@@ -0,0 +1,66 @@
+! CCE 19, 20, 21: lastprivate on a composite target teams distribute
+! parallel do is wrong, and varies between runs, when the parallel leaf
+! runs with num_threads(2) -- or with if(parallel: .false.) and no
+! num_threads. Neither collapse nor simd is needed (fix:
+! this 10-line program replaces the collapse(2)/simd/num_threads(32)
+! reproducer reduced from the 14-clause stress program; the
+! file keeps its name so its links stay).
+! Spec: lp is assigned in every iteration, so "the value of each new list
+! item from the sequentially last iteration of the associated loops ... is
+! assigned to the original list item" (OpenMP 5.2 §5.4.5 p.115 l.12-16),
+! and on a combined target construct the list item is also map(tofrom)
+! (§17.2 p.340 l.27-30). Race-free: i is the loop's iteration variable.
+! Expected: lp= 200
+! Observed (Tuolumne MI300A, -O2, OMP_TARGET_OFFLOAD=mandatory, 10 runs per
+! cell, 2026-10-26; data/evidence/gate_probe/logs/lastprivate_simdred.txt, programs
+! in data/evidence/gate_probe/lastprivate/):
+! - this program (nt2): CCE 19, 20 and 21 at HSA_XNACK 0 and 1: lp= 0, 61,
+!   125 or 189, varying from run to run (200 in none of the 60 runs; this
+!   file as committed, which drops nt2's unused lpar: the same, 0 of 60,
+!   data/evidence/gate_probe/logs/reduce.txt lpfind);
+! - if(parallel: lpar) with lpar = .false. instead of num_threads(2)
+!   (ifpar): the same values on all six cells;
+! - with collapse(2) (collapsent2) or simd (simdnt2) added: the same;
+! - control, the same directive without num_threads and if (nont): lp= 200
+!   in 60 of 60 runs on CCE 19/20/21, both modes.
+! Mechanism: CCE 19/20/21 warn at compile time, on this file
+! and on the if(parallel: .false.) form but not on the control:
+!   ftn-7256 ftn: WARNING P, File = lp.f90, Line = <the directive>
+!   An OpenMP parallel construct in a target region is limited to a single
+!   thread.
+! (data/evidence/gate_probe/logs/lastprivate_compile.txt). Both triggers make CCE
+! run the parallel leaf with one thread; so the defect is that lastprivate
+! is lost when CCE serializes the parallel leaf of a composite distribute
+! parallel do. The warning says nothing about lastprivate: it is not a
+! diagnostic of the wrong value, and one thread must still leave lp = 200.
+! The earlier reproducer (num_threads(32) on target teams distribute
+! parallel do simd collapse(2) over 16 x 8 iterations: lp= 0, 20, 64 or
+! 100, correct with num_teams(1) or num_teams(3),
+! data/reports/fuzz-stress-audit/r7-*.f90) is this defect; so are the
+! lastprivate cells of the reproduction gate's review queue
+! (data/reports/gate-queue.md: fuzz and evidence programs with
+! lastprivate on distribute parallel do with num_threads(2..8) or
+! if(parallel: .false.), and the 14-clause stress program clauses-omp-16).
+! Another family: AFAR amdflang gives lp= 200 in 20 of 20 runs (XNACK 1 and
+! 0) on the simd form (simdnt2); on this form it stops with "not yet
+! implemented: lastprivate clause in constructs other than
+! simd/worksharing-loop/taskloop" (a compile failure, not a value).
+! NVHPC documents lastprivate on distribute as unsupported (HPC Compilers
+! User's Guide 25.11 §7.4, 2.9.4), so it is no witness here.
+! CCE: ftn -fopenmp -O2 (module load cce/<v> craype-accel-amd-gfx942 rocm)
+! Run: OMP_TARGET_OFFLOAD=mandatory HSA_XNACK=0 (or 1) ./a.out
+program p
+  implicit none
+  integer :: i, lp
+  lp = 0
+  !$omp target teams distribute parallel do lastprivate(lp) num_threads(2)
+  do i = 1, 200
+    lp = i
+  end do
+  !$omp end target teams distribute parallel do
+  print '(a,i0)', 'lp= ', lp
+end program p
+! site:
+! title: ftn: lastprivate on target teams distribute parallel do simd collapse(2) with num_threads gives a varying wrong value
+! control: ../vendor/checks/src/cce/control/cce-lastprivate-num-threads-collapse-simd-control.f90 num_threads(32) removed
+! end site

offload/_root/data/findings/stress/cce-teams-reduction-many-teams-wrap.f90

@@ -0,0 +1,55 @@
+! # Draft finding: data/reports/fuzz-stress-audit/r6-teams-reduction-65536.f90 on cce19
+!
+! - compiler: cce19
+! - toolchain: cce19; arch: gfx942; machine: tuolumne; memory mode: copy; opt: -O2
+! - program: file data/reports/fuzz-stress-audit/r6-teams-reduction-65536.f90 (f90, version 52, sha256 3713620f5e7f1159)
+! - expected: s= 8455717314 (trusted; elision + metamorphic + model)
+! - actual: wrong_answer s= 626787243 (expected s= 8455717314)
+! - verdict: compiler_bug by rule R20-runtime-bug: a legal program fails at run time, deterministically, against an expected value
+!   from two or more independent sources with an executed witness, and another toolchain, mode, arch or the elision gives the
+!   expected value
+! - reason: expected trusted s= 8455717314 (elision + metamorphic + model): elision + metamorphic + model agree; witnesses:
+!   afar/gfx942/copy, cce21/gfx942/copy, elision
+! - citations: RUL-DERIVED-NEEDS-EXECUTION (rulings.md); RUL-WITNESS-PER-MODE (rulings.md);
+!   RUL-SAME-COMPILER-RUNS (rulings.md); RUL-PRESENCE-WITNESS (rulings.md); RUL-METAMORPHIC-OTHER-FAMILY
+!   (rulings.md)
+! - legality: legal: read against the spec (audit and re-review); checked by scope, offload.engine.rules, flang (no checker of
+!   the family under test)
+! - witnesses: afar/gfx942/copy, cce21/gfx942/copy, elision
+! - withdrawn: none
+!
+! Audit, candidate 6: a teams reduction over 2**24 iterations with
+! num_teams(65536). All variables are integer(8); the sum is 8455717314 (more
+! than 2**32). Expected: s= 8455717314
+program teams_reduction
+  implicit none
+  integer(8) :: i, s, nn
+  nn = 16777216_8
+  s = 0
+  !$omp target teams distribute parallel do num_teams(65536) thread_limit(256) reduction(+: s)
+  do i = 1, nn
+    s = s + mod(i * 715_8, 1009_8)
+  end do
+  !$omp end target teams distribute parallel do
+  print '(a,i0)', 's= ', s
+end program teams_reduction
+! spec (requirement): a reduction clause on a teams construct gives the initial task of every team a private copy of the list
+!   item, and at the end of the region the original list item is combined with the final value of every private copy, whatever
+!   number of teams (within the num_teams bounds) was created, so the sum does not depend on num_teams.
+! "For the teams construct, one or more private copies of each list item are created for the initial task of each team in the
+!   league, as if the private clause had been used. For the loop construct, private copies are created and used in the construct
+!   according to the description and restrictions in Section 5.3. At the end of a region that corresponds to a construct for which
+!   the reduction clause was specified, the original list item is updated by combining its original value with the final value of
+!   each of the private copies, using the combiner of the specified reduction-identifier." (5.2 §5.5.8 p.135 l.4-10)
+! "The num_teams clause specifies the bounds on the number of teams created by the construct on which it appears. lower-bound
+!   specifies the lower bound and upper-bound specifies the upper bound on the number of teams requested. If lower-bound is not
+!   specified, the effect is as if lower-bound is specified as equal to upper-bound. The number of teams created is implementation
+!   defined, but it will be greater than or equal to the lower bound and less than or equal to the upper bound." (5.2 §10.2.1
+!   p.233 l.10-15)
+! spec (this program): the target teams distribute parallel do reduction(+: s) with num_teams(65536) must give the same sum as
+!   any other legal team count (8455717314); CCE 19 returns a different value, while num_teams(8192) is correct.
+! site:
+! title: A reduction on target teams distribute parallel do with num_teams(65536) gives a wrong sum (8192 teams is correct)
+! control: ../vendor/checks/src/cce/control/cce-teams-reduction-many-teams-wrap-control.f90 num_teams(8192) instead of
+! + num_teams(65536)
+! end site

offload/_root/data/findings/stress/cce21-declare-target-scalar-map-write-lost.f90

@@ -0,0 +1,58 @@
+! # Draft finding: data/reports/fuzz-stress-audit/r4-declare-target-scalar-control.f90 on cce21
+!
+! - compiler: cce21
+! - toolchain: cce21; arch: gfx942; machine: tuolumne; memory mode: copy; opt: -O2
+! - program: file data/reports/fuzz-stress-audit/r4-declare-target-scalar-control.f90 (f90, version 52, sha256 28c79fb1fd5b8dc7)
+! - expected: g= 203 dev= 1 (trusted; metamorphic + model)
+! - actual: wrong_answer g= 101 dev= 1 (expected g= 203 dev= 1)
+! - verdict: compiler_bug by rule R20-runtime-bug: a legal program fails at run time, deterministically, against an expected value
+!   from two or more independent sources with an executed witness, and another toolchain, mode, arch or the elision gives the
+!   expected value
+! - reason: expected trusted g= 203 dev= 1 (metamorphic + model): metamorphic + model agree; witnesses: afar/gfx942/copy,
+!   cce19/gfx942/copy, cce20/gfx942/copy
+! - citations: RUL-DERIVED-NEEDS-EXECUTION (rulings.md); RUL-WITNESS-PER-MODE (rulings.md);
+!   RUL-SAME-COMPILER-RUNS (rulings.md); RUL-PRESENCE-WITNESS (rulings.md); RUL-METAMORPHIC-OTHER-FAMILY
+!   (rulings.md)
+! - legality: legal: read against the spec (audit and re-review); checked by scope, offload.engine.rules, flang (no checker of
+!   the family under test)
+! - witnesses: afar/gfx942/copy, cce19/gfx942/copy, cce20/gfx942/copy
+! - withdrawn: none
+!
+! Audit, candidate 4, CONTROL (explicit map(tofrom: g)) of a declare target module scalar.
+! Basis (N3): g appears in an enter clause (the 5.0 declare target(list) form), so its
+! corresponding list item "is never removed from those device data environments as if its reference count
+! was initialized to positive infinity" (5.2 §5.8.4 p.159 l.10-14; 5.0 §2.12.7 p.182 l.19-22). On entry to the
+! target region the storage is present and its count is not one, so no new list item is created and no
+! "to" transfer happens (5.2 §5.8.3 p.153 l.1-17, steps 1-3); on exit the count is not one, so no "from"
+! transfer happens and an infinite count is not decremented (p.153 l.31-35, p.154 l.1-11). The region therefore reads and
+! writes the declare target copy (101 -> 203), and "target update from(g)" returns 203. This is the same
+! result as the implicit form (5.2 §5.8.1 p.148 l.9-11 treats it "as if" this map clause appeared). No
+! restriction forbids an explicit map of a declare target variable (5.2 §5.8.3 p.156-157, §7.8 p.205,
+! §7.8.1 p.206, §13.8 p.286-287). Expected: g= 203 dev= 1. CCE 21 without the map (r4-declare-target-
+! scalar.f90) gives 203; CCE 19/20, AFAR and NVHPC give 203 with the map.
+module dt_scalar_m
+  implicit none
+  integer(8) :: g
+  !$omp declare target(g)
+end module dt_scalar_m
+program declare_target_scalar
+  use omp_lib
+  use dt_scalar_m
+  implicit none
+  integer :: dev
+  g = 101
+  dev = -1
+  !$omp target update to(g)
+  !$omp target map(tofrom: dev, g)
+    g = 2 * g + 1
+    dev = merge(0, 1, omp_is_initial_device())
+  !$omp end target
+  !$omp target update from(g)
+  print '(a,i0,a,i0)', 'g= ', g, ' dev= ', dev
+end program declare_target_scalar
+! site:
+! title: ftn: write to a declare target module scalar named in map(tofrom:) is lost
+! control: ../vendor/checks/src/cce/control/cce21-declare-target-scalar-map-write-lost-control.f90 g not in the map clause
+! + (implicitly
+! + tofrom)
+! end site

offload/_root/data/findings/stress/controls/gcc-declare-target-allocatable-component-control.f90

@@ -0,0 +1,29 @@
+! Control of stress/gcc-declare-target-allocatable-component-ice.f90: the same program without the declare target
+! directive (compiles; correct on gcc_g90 and gcc_sm80).
+module dt_m
+  implicit none
+  type :: holder
+    integer, allocatable :: v1(:)
+  end type holder
+  type(holder) :: gq
+end module dt_m
+
+program declared_alloc_component
+  use omp_lib, only: omp_is_initial_device
+  use dt_m
+  implicit none
+  integer :: out(64), i, host_flag
+  allocate(gq%v1(64))
+  gq%v1 = [(3*i, i = 1, 64)]
+  !$omp target enter data map(to: gq%v1)
+  out = 0
+  host_flag = 1
+  !$omp target teams distribute parallel do map(tofrom: out, host_flag)
+  do i = 1, 64
+    if (i == 1) host_flag = merge(1, 0, omp_is_initial_device())
+    out(i) = gq%v1(i) + 1
+  end do
+  !$omp target exit data map(delete: gq%v1)
+  print '(a,i0)', 'sum= ', sum(out)
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', sum(out) == 3*64*65/2 + 64)
+end program declared_alloc_component

offload/_root/data/findings/stress/gcc-declare-target-allocatable-component-ice.f90

@@ -0,0 +1,61 @@
+! # Finding (GCC 16.2, stress sweeps): a declare target module variable of a derived type with an allocatable component in a
+!   target region: internal compiler error in lower_omp_target
+!
+! - toolchains: gcc_g90 (GCC 16.2.0, AMD Instinct MI250X gfx90a, Tioga) and gcc_sm80 (GCC 16.2.0, NVIDIA A100 sm_80, wingtip);
+!   separate memory only; -O2
+! - build: gfortran -fopenmp -foffload=amdgcn-amdhsa -foffload-options=amdgcn-amdhsa=-march=gfx90a -O2 (gcc_g90);
+!   -foffload=nvptx-none -foffload-options=nvptx-none=-march=sm_80 -foffload-options=nvptx-none=-latomic -O2 (gcc_sm80)
+! - failure: ice: internal compiler error: in lower_omp_target
+! - observed: `internal compiler error: in lower_omp_target, at omp-low.cc:13204` ("during GIMPLE pass: omplower") at the target
+!   teams distribute parallel do directive, on both targets (the host compiler fails before any offload code is made)
+! - expected: compiles; prints `sum= 6304` and `RESULT ran_on_host=0 check=pass`
+! - rule: a variable may appear in a declare target directive in the specification part of a module ("If an extended list item is a
+!   variable name, the directive must appear in the specification part of a subroutine subprogram, function subprogram, program or
+!   module", 5.2 §7.8.1 p.206 l.27-28); its allocatable component is mapped by the enter data construct.
+! - same-compiler control (compiles; correct, gcc_sm80: mandatory pass 5 of 5; unset pass 5 of 5; gcc_g90: mandatory pass 5 of 5;
+!   unset pass 5 of 5 (results/parity/<machine>/<tc>/probes.jsonl)): the same program without the declare target directive
+!   (controls/gcc-declare-target-allocatable-component-control.f90).
+! - other families: AFAR, CCE 19/20/21 and NVHPC 25.11/26.9 run the stress programs (template.declared_alloc-omp-8/159/400-1, eight
+!   allocatable components) correctly in copy mode (results/stress/s1-g5, nv1-omp). The site's finding matrix runs this file on
+!   every compiler.
+! - stress programs (6 cells (3 gcc_g90, 3 gcc_sm80); gate: confirmed 6; the stress kind has no confirmer path):
+!   template.declared_alloc-omp-159-1, template.declared_alloc-omp-400-1, template.declared_alloc-omp-8-1
+! - legality: the stress programs pass the stress gate and the pre-run check (offload.engine.prerun.check: the rules and AFAR's
+!   front
+!   end, two witnesses; results/parity/stress-checked); GCC is a compiler under test only and never a legality witness.
+module dt_m
+  implicit none
+  type :: holder
+    integer, allocatable :: v1(:)
+  end type holder
+  type(holder) :: gq
+  !$omp declare target(gq)
+end module dt_m
+
+program declared_alloc_component
+  use omp_lib, only: omp_is_initial_device
+  use dt_m
+  implicit none
+  integer :: out(64), i, host_flag
+  allocate(gq%v1(64))
+  gq%v1 = [(3*i, i = 1, 64)]
+  !$omp target enter data map(to: gq%v1)
+  out = 0
+  host_flag = 1
+  !$omp target teams distribute parallel do map(tofrom: out, host_flag)
+  do i = 1, 64
+    if (i == 1) host_flag = merge(1, 0, omp_is_initial_device())
+    out(i) = gq%v1(i) + 1
+  end do
+  !$omp target exit data map(delete: gq%v1)
+  print '(a,i0)', 'sum= ', sum(out)
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', sum(out) == 3*64*65/2 + 64)
+end program declared_alloc_component
+! site:
+! title: declare target module variable with an allocatable component used in a target region: internal compiler error
+! summary: A module variable of a derived type with an allocatable component, named in a declare target directive and read
+! + in a target teams distribute parallel do loop after its component is mapped by target enter data, stops GCC 16.2 with an
+! + internal compiler error (lower_omp_target) for both offload targets. Without the declare target directive the program
+! + compiles and runs correctly. AFAR, CCE and NVHPC run the stress programs correctly.
+! control: stress/controls/gcc-declare-target-allocatable-component-control.f90 the same program without declare target
+! end site

offload/_root/data/findings/stress/nvhpc-acc-derived-type-component-not-copied.f90

@@ -0,0 +1,33 @@
+! # Finding: NVHPC OpenACC does not copy back a derived-type variable
+! # written through a component in a serial construct
+!
+! - compilers: NVHPC nvfortran 25.11 and 26.9, A100 (sm_80), -acc=gpu -gpu=cc80, separate and
+!   managed memory, -O2
+! - expected: c1= 203. xc has an exposed access in the serial construct and no visible data clause;
+!   in that case "An aggregate variable will be treated as if it appears either: ... In a copy
+!   clause otherwise" (OpenACC 3.4 §2.6.2 p.41 l.1388-1391). The access to xc%c1 is an access to xc (§2.6.2 l.1374), and a
+!   derived type is a composite type, hence an aggregate (glossary p.159 l.5792-5796, 5807-5811)
+! - actual: c1= 101 on both releases and both memory modes
+! - control (same compiler): serial copy(xc) (data/reports/fuzz-stress-audit/r5-acc-component-control.f90):
+!   203 on both releases and modes
+! - other families: CCE 19/20/21 (ftn -h acc) give 203 on this program (MI300A HSA_XNACK 1 and 0, MI250X)
+! - legality: legal by reading: serial runs one gang, one worker, one vector lane; xc is a local
+!   variable of the main program
+! - evidence: results/stress/audit/runs-nvhpc.jsonl. The confirmer gave needs_human (R22, no
+!   cross-machine witness); the audit counts the MI300A results
+program acc_component
+  implicit none
+  type :: t
+    integer(8) :: c1
+  end type t
+  type(t) :: xc
+  xc%c1 = 101
+  !$acc serial
+    xc%c1 = 2 * xc%c1 + 1
+  !$acc end serial
+  print '(a,i0)', 'c1= ', xc%c1
+end program acc_component
+! site:
+! title: nvfortran -acc: derived-type variable without a data clause is not copied back from a serial region
+! control: ../vendor/checks/src/nvhpc/control/nvhpc-acc-derived-type-component-not-copied-control.f90 serial copy(xc)
+! end site

offload/_root/data/findings/stress/nvhpc-c-lastprivate-teams-distribute-parallel-for-lost.c

@@ -0,0 +1,62 @@
+/* # Finding: NVHPC accepts lastprivate on target teams distribute
+   # parallel for, which its guide documents as unsupported, and gives a wrong answer (C)
+
+   - class: an unsupported clause accepted silently with a wrong answer, the R6
+     report-candidate class (as nvhpc-depend-inoutset-ignored.f90); a support claim it contradicts
+     is partial_support (data/reports/rulings.md, documented limitations), not a compiler bug in a
+     documented feature. NVIDIA HPC Compilers User's Guide 25.11 (and 26.9), §7.4 OpenMP Subset:
+       2.9.4 Distribute Directives: "The lastprivate clause is not supported"
+       2.14 Clauses on Combined and Composite Constructs: "Clauses on combined constructs are
+       supported to the extent that the clauses are supported on the component constructs."
+     On this construct lastprivate applies to the distribute and for leaves (5.2 §17.2), so it is
+     not supported here. nvc gives no diagnostic. The claim is catalog/omp/claims.yaml
+     onleaf.distribute.lastprivate (the triage reads it).
+   - compilers: NVHPC nvc 25.11 and 26.9, A100 (sm_80), -mp=gpu -gpu=cc80, separate and managed
+     memory, -O2
+   - expected: l= 2560 dev= 1. lastprivate gives the original l the value of the sequentially last
+     iteration (i = 64: 64 * 40) (5.2 §5.4.5; §17.2 p.340 l.21-30 applies it to the distribute and
+     for leaves), and map(tofrom: l) on the target leaf brings it back to the host. The explicit
+     map is legal: 5.2 §13.8 p.286 l.29-30 restricts only data-sharing clauses applied to the target
+     leaf, and the 5.0 §2.19.7.1 restriction (p.321 l.25-26) exempts combined constructs
+   - actual: l= 0 dev= 1, both releases, both memory modes
+   - same-compiler controls, all l= 2560 on both releases and modes
+     (data/reports/fuzz-stress-audit/, runs in results/stress/audit/runs-nvhpc-fix2.jsonl):
+       lp-c-tdpf-red.c   the same construct and loop with reduction(max: l) instead of lastprivate
+       lp-c-tdpf-copy.c  the same construct, private(l), the last iteration stores l in a mapped array
+       lp-c-tdist-map.c  target teams distribute lastprivate(l) map(tofrom: l) (no parallel for)
+       lp-c-tpfor-map.c  target parallel for lastprivate(l) map(tofrom: l) (no teams distribute)
+       lp-c-tdist-split.c target map(tofrom: l) around teams distribute lastprivate(l)
+     The worksharing-loop form (lp-c-tpfor-map.c) uses a documented clause ("The lastprivate clause
+     is supported", 2.9.2) and gives 2560. The distribute-only forms (lp-c-tdist-map.c,
+     lp-c-tdist-split.c) also give 2560, but that is undocumented behaviour: the guide says
+     lastprivate on distribute is not supported. So the composite gives a wrong answer for a clause
+     the guide excludes; the controls show that the value can be returned, not that nvc supports it.
+   - other families: AFAR amdclang gives 2560 on this program (MI300A HSA_XNACK 1 and 0, MI250X).
+     CCE craycc gives 0 here too (see data/reports/fuzz-stress.md, candidate 2b).
+   - related, not the same: nvhpc-c-parallel-for-firstprivate-in-target.c is a compile failure
+     ("Failed to translate OpenMP region") of a parallel for nested in a target region; this program
+     compiles and runs a combined construct. Without the map (r2-lastprivate-combined.c and
+     lp-c-tdist.c) nvc also gives 0: the missing implicit map, the C form of
+     stress/nvhpc-lastprivate-combined-target-not-mapped.f90.
+   - legality: legal by reading: the for loop variable is private; only the lastprivate item l is
+     written in the loop; dev is written by the initial thread of the second target region
+   - evidence: tools/jobs/run_wingtip_fix2.sh (tools/campaigns/stress_audit.py); the confirmer was not run on it */
+#include <stdio.h>
+#include <omp.h>
+int main(void) {
+  long long l = 0;
+  int dev = -1;
+  #pragma omp target teams distribute parallel for lastprivate(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: nvc -mp=gpu: lastprivate on target teams distribute parallel for accepted silently, value lost
+// control: ../vendor/checks/src/nvhpc/control/nvhpc-c-lastprivate-teams-distribute-parallel-for-lost-control.c reduction(max: l)
+// + instead of
+// + lastprivate(l)
+// end site