offtarget 0.1.0__py3-none-any.whl

offload/_root/data/findings/fuzz/nvhpc-defaultmap-to-scalar-reduction-lost.f90

@@ -0,0 +1,82 @@
+! # Finding (parity-fuzz-c1): NVHPC: a reduction on a combined target construct that also has defaultmap(to: scalar) is not copied
+! # back; the reduction variable keeps its initial value on the host
+!
+! - toolchains and modes that fail: nvhpc (NVHPC 25.11), nvhpc269 (NVHPC 26.9); modes: copy, managed; -O2
+! - build: nvfortran -mp=gpu -gpu=cc80 -gpu=mem:separate -O2
+! - failure: wrong_answer (check=fail)
+! - observed: `r= 0 h= 0` with `check=fail`; identical signature on 4 of 4 failing cells
+! - expected: compiles and prints `r= 2080 h= 0` with `check=pass`
+! - rule: "When specified, explicit data-environment attribute clauses on target directives determine the attributes for variables
+!   referenced in a target construct. Otherwise, the first matching rule from the following list determines the implicit
+!   data-mapping (or data-sharing) attribute" (5.2 §5.8.1 p.148 l.2-5); the first rule that matches r is "If a variable is the base
+!   variable of a list item in a reduction, lastprivate or linear clause on a combined target construct then the list item is
+!   treated as if it had appeared in a map clause with a map-type of tofrom if Section 17.2 specifies this behavior" (5.2 §5.8.1
+!   p.148 l.12-14), which comes before the defaultmap rule (5.2 §5.8.1 p.148 l.18-19), and Section 17.2 does specify it: "If a list
+!   item in a reduction clause on a combined target construct does not have the same base variable or base pointer as a list item
+!   in a map clause on the construct, then the effect is as if the list item in the reduction clause appears as a list item in a
+!   map clause with a map-type of tofrom" (5.2 §17.2 p.341 l.10-13). OpenMP 5.0 orders the rules the same way: "If a list item
+!   appears in a reduction, lastprivate or linear clause on a combined target construct then it is treated as if it also appears
+!   in a map clause with a map-type of tofrom" (5.0 §2.19.7 p.314 l.14-16) precedes its defaultmap rule (5.0 §2.19.7 p.314 l.20-21)
+! - vendor: "The defaultmap clause is supported using OpenMP 5.0 semantics." and "The reduction clause is supported." (NVIDIA HPC
+!   Compilers User's Guide 26.9, Using OpenMP, items 2.19.7 and 2.19.5; data/index/claims/nvidia-hpc-26.9-user-guide-openmp.txt)
+! - variants: files next to the reduction in results/parity/nvc1/red/, rows results/parity/nvc1/wt.dm.jsonl (both releases, separate
+!   and managed memory) and results/parity/nvc1/tuo.dm.jsonl: target teams distribute parallel do
+!   (nvhpc-defaultmap-to-scalar-reduction-teams-variant.f90), target simd (nvhpc-defaultmap-to-scalar-reduction-simd-variant.f90)
+!   and the seed's reduction(min:) with the same reduction on a nested simd loop
+!   (nvhpc-defaultmap-to-scalar-reduction-min-nested-simd-variant.f90) lose the value too on both releases; with defaultmap(tofrom:
+!   scalar) in place of defaultmap(to: scalar) (nvhpc-defaultmap-tofrom-scalar-reduction-variant.f90) the result is right. Not
+!   evidence: with defaultmap(firstprivate: scalar) (nvhpc-defaultmap-firstprivate-scalar-reduction-variant.f90) both releases stop
+!   in the LLVM optimizer (`opt: ... error: integer constant must have integer type`, a harness error) and AFAR's flang reports
+!   "not yet implemented: Firstprivate is currently unsupported defaultmap behaviour"; a lead, not reduced
+! - found by: c1 program par-c1-nvhpc-nvhpc269:962, whose campaign failure is the depend fault of
+!   nvhpc-depend-implicit-map-illegal-address.f90 (error 719 at cuEventQuery); with its depend and nowait clauses removed it runs
+!   and only r1a is wrong, the reduction(min: r1a) of a target parallel do with defaultmap(to: scalar)
+!   (exploration, not rows). No campaign cell has this signature alone, so no programs are counted
+!   here (962's
+!   campaign cell is related to, and not counted in, the depend finding either)
+! - same-compiler control: controls/nvhpc-defaultmap-to-scalar-removed-control.f90 (one change from this file; correct on nvhpc
+!   (NVHPC 25.11), nvhpc269 (NVHPC 26.9); rows results/parity/nvc1/tuo.dm.jsonl, results/parity/nvc1/wt.dm.jsonl);
+!   controls/nvhpc-defaultmap-to-scalar-reduction-mapped-control.f90 (one change from this file; correct on nvhpc (NVHPC 25.11),
+!   nvhpc269 (NVHPC 26.9); rows results/parity/nvc1/tuo.dm.jsonl, results/parity/nvc1/wt.dm.jsonl)
+! - other families: afar (AFAR 24.3.0), cce19 (CCE 19.0.0), cce20 (CCE 20.0.2) run the file correctly (rows
+!   results/parity/nvc1/tuo.dm.jsonl); cce21 (CCE 21.0.3), cce21_4 (CCE 21.0.4) fail it another way, e.g. `r= 2080 h= -1` with
+!   `check=fail`
+! - gate and confirmer: 4 of 4 cells reproduce in all four environments (a-d; (c) on another node or GPU than (a); rows
+!   results/parity/nvc1/gate_abd.dm.jsonl, results/parity/nvc1/gate_abd.dm.m2.jsonl, results/parity/nvc1/gate_c.dm.jsonl,
+!   results/parity/nvc1/gate_c.dm.m2.jsonl, results/parity/nvc1/wt.dm.jsonl)
+! - legality: the rules (offload.engine.rules) and AFAR's flang front end accept this file, both controls and the four
+!   defaultmap(to:)
+!   and defaultmap(tofrom:) variants (offload.engine.prerun.check on a Tuolumne compute node;
+!   results/parity/nvc1/prerun.dm.txt); AFAR
+!   24.3.0 and CCE 19/20 compile and run the file, both controls and those four variants correctly with HSA_XNACK 0 and 1
+!   (results/parity/nvc1/tuo.dm.jsonl). The firstprivate variant is not evidence: AFAR stops at "not yet implemented" and only CCE
+!   19/20 run it. CCE 21/21.0.4 reduce r correctly on the file and every variant but do not copy back the explicitly mapped h
+!   (`r= 2080 h= -1`): their documented defect cce21-defaultmap-aggregate-flag.f90 (a defaultmap clause on target stops the
+!   copy-back of a map(tofrom:) scalar), not this one. NVHPC is the compiler under test and is not counted as a witness
+program p
+  use omp_lib, only: omp_is_initial_device
+  implicit none
+  integer :: a(64)
+  integer :: i, r, h
+  a = [(i, i = 1, 64)]
+  r = 0
+  h = -1
+  !$omp target parallel do map(to: a) map(tofrom: h) defaultmap(to: scalar) reduction(+: r)
+  do i = 1, 64
+    if (i == 1) h = merge(1, 0, omp_is_initial_device())
+    r = r + a(i)
+  end do
+  !$omp end target parallel do
+  print '(a,i0,a,i0)', 'r= ', r, ' h= ', h
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', merge(1, 0, h == 1), ' check=', merge('pass', 'fail', r == 2080 .and. h == 0)
+end program p
+
+! site:
+! title: defaultmap(to: scalar) drops a reduction's copy-back
+! summary: nvfortran -mp=gpu appears to behave incorrectly on a reduction on a combined target construct that also has
+! + defaultmap(to: scalar): the reduction variable keeps its initial value on the host. Without the defaultmap clause, or with the
+! + variable in a map(tofrom:) clause, the result is right.
+! control: fuzz/controls/nvhpc-defaultmap-to-scalar-removed-control.f90 one change from the finding; correct on nvhpc, nvhpc269
+! control: fuzz/controls/nvhpc-defaultmap-to-scalar-reduction-mapped-control.f90 one change from the finding; correct on nvhpc,
+! + nvhpc269
+! end site

offload/_root/data/findings/fuzz/nvhpc-depend-implicit-map-illegal-address.f90

@@ -0,0 +1,81 @@
+! # Finding (parity-fuzz-c1): NVHPC: a target construct whose depend clause names an array that the construct maps only implicitly
+! # ends in CUDA_ERROR_ILLEGAL_ADDRESS
+!
+! - toolchains and modes that fail: nvhpc (NVHPC 25.11), nvhpc269 (NVHPC 26.9); modes: copy, managed; -O2
+! - build: nvfortran -mp=gpu -gpu=cc80 -gpu=mem:separate -O2
+! - failure: run_error
+! - observed: `Accelerator Fatal Error: call to cuEventQuery returned error 700 (CUDA_ERROR_ILLEGAL_ADDRESS): Illegal address during
+!   kernel execution`, exit status 1, and the same without OMP_TARGET_OFFLOAD=mandatory (the rows' stderr; the harness's reason
+!   reads `exit_status: 1; without mandatory: exit_status: 1`); identical signature on 4 of 4 failing cells
+! - expected: compiles and prints `sum= 2080` with `check=pass`
+! - rule: "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), and on a target construct "If a depend clause is present, it is associated with the target task" (5.2 §13.8
+!   p.284 l.14-15): the depend clause orders the target task and does not change how `a` is mapped
+! - vendor: "Any task-generating target construct can have depend and nowait clauses" (NVIDIA HPC Compilers User's Guide 26.9, Using
+!   OpenMP, the mapping of depend and nowait to CUDA streams; data/index/claims/nvidia-hpc-26.9-user-guide-openmp.txt), and the
+!   target
+!   construct's depend clause is listed as supported (the guide's OpenMP subset, item 2.12.5)
+! - same-compiler control: controls/nvhpc-depend-explicit-map-control.f90 (one change from this file; correct on nvhpc (NVHPC
+!   25.11), nvhpc269 (NVHPC 26.9); rows results/parity/nvc1/tuo.dep.jsonl, results/parity/nvc1/wt.dep.jsonl);
+!   controls/nvhpc-depend-removed-control.f90 (one change from this file; correct on nvhpc (NVHPC 25.11), nvhpc269 (NVHPC 26.9);
+!   rows results/parity/nvc1/tuo.dep.jsonl, results/parity/nvc1/wt.dep.jsonl)
+! - other families: afar (AFAR 24.3.0), cce19 (CCE 19.0.0), cce20 (CCE 20.0.2), cce21 (CCE 21.0.3), cce21_4 (CCE 21.0.4) run the
+!   file correctly (rows results/parity/nvc1/tuo.dep.jsonl)
+! - gate and confirmer: 4 of 4 cells reproduce in all four environments (a-d; (c) on another node or GPU than (a); rows
+!   results/parity/nvc1/gate_abd.dep.jsonl, results/parity/nvc1/gate_abd.dep.m2.jsonl, results/parity/nvc1/gate_c.dep.jsonl,
+!   results/parity/nvc1/gate_c.dep.m2.jsonl, results/parity/nvc1/wt.dep.jsonl); campaign gate of the programs below: 22 cells,
+!   20 confirmed in the four environments (a-d; (c) on another node or GPU; rows
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.abd.127709.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.abd.127721.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.abd.2465893.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.abd.2476695.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.c.210952.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.c.210965.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.c.3354124.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.c.3482833.jsonl); the campaign gate's
+!   verdict is confirmed for all 22 cells; the other 2 (1766 on both releases) were rerun in (b) and (c) only
+! - programs (11): par-c1-nvhpc-nvhpc269:1014, par-c1-nvhpc-nvhpc269:1115, par-c1-nvhpc-nvhpc269:1147,
+!   par-c1-nvhpc-nvhpc269:1274, par-c1-nvhpc-nvhpc269:1316, par-c1-nvhpc-nvhpc269:1766, par-c1-nvhpc-nvhpc269:1878,
+!   par-c1-nvhpc-nvhpc269:2302, par-s1-nvhpc-nvhpc269:1984, par-s1-nvhpc-nvhpc269:2459, par-s1-nvhpc-nvhpc269:4050. The three s1
+!   programs name an array the construct maps only implicitly (ds, ic, xr8) in a depend clause with nowait, fail with
+!   cuEventQuery error 700 on both releases, and give the expected checksum with their depend and nowait clauses removed
+! (exploration)
+! - related, not counted: par-c1-nvhpc-nvhpc269:962 ends with error 719 (CUDA_ERROR_LAUNCH_FAILED) at cuEventQuery rather than 700,
+!   and its depend lists name arrays that are present through an enclosing target data region (o1 also in an explicit map clause)
+!   rather than arrays the construct maps implicitly; with depend and nowait removed it runs, with one wrong value that is the
+!   defect of nvhpc-defaultmap-to-scalar-reduction-lost.f90 (exploration, not rows)
+! - legality: the rules (offload.engine.rules) and AFAR's flang front end accept this file and both controls
+!   (offload.engine.prerun.check on
+!   a Tuolumne compute node; results/parity/nvc1/prerun.dep.txt); AFAR 24.3.0 and CCE 19/20/21/21.0.4 compile and run it correctly
+!   with HSA_XNACK 0 and 1 (results/parity/nvc1/tuo.dep.jsonl). NVHPC is the compiler under test and is not counted as a witness
+program p
+  use omp_lib, only: omp_is_initial_device
+  implicit none
+  integer :: a(64)
+  integer :: i, s, host
+  a = 0
+  host = 1
+  !$omp target map(tofrom: host) nowait depend(inout: a)
+  do i = 1, 64
+    a(i) = i
+  end do
+  if (omp_is_initial_device()) then
+    host = 1
+  else
+    host = 0
+  end if
+  !$omp end target
+  !$omp taskwait
+  s = sum(a)
+  print '(a,i0)', 'sum= ', s
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', host, ' check=', merge('pass', 'fail', s == 2080)
+end program p
+
+! site:
+! title: depend naming an implicitly mapped array: illegal address
+! summary: nvfortran -mp=gpu appears to behave incorrectly when a target construct's depend clause names an array that the construct
+! + maps only implicitly: the kernel ends in CUDA_ERROR_ILLEGAL_ADDRESS. With the array in a map clause, or without the depend
+! + clause, the result is right.
+! control: fuzz/controls/nvhpc-depend-explicit-map-control.f90 one change from the finding; correct on nvhpc, nvhpc269
+! control: fuzz/controls/nvhpc-depend-removed-control.f90 one change from the finding; correct on nvhpc, nvhpc269
+! end site

offload/_root/data/findings/fuzz/nvhpc-distribute-parallel-num-threads-writes-lost.f90

@@ -0,0 +1,79 @@
+! # Finding (parity-fuzz-c1): NVHPC 25.11: the writes of a worksharing loop in a parallel region with a num_threads clause nested in
+! # a distribute loop never reach the array (26.9 correct)
+!
+! - toolchains and modes that fail: nvhpc (NVHPC 25.11); modes: copy, managed; -O2
+! - build: nvfortran -mp=gpu -gpu=cc80 -gpu=mem:separate -O2
+! - failure: wrong_answer (check=fail)
+! - observed: `sum= 0 h= 0` with `check=fail`; identical signature on 2 of 2 failing cells
+! - expected: compiles and prints `sum= 2432 h= 0` with `check=pass`
+! - rule: "The num_threads clause specifies the desired number of threads to execute a parallel region." (5.2 §10.1.2 p.227 l.23)
+!   and "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): the clause only sizes the team; o2 is shared by the teams, the distribute loop and the nested parallel
+!   region, written by the worksharing loop and copied back when the target region ends
+! - vendor: "The num_threads, default, private, firstprivate, and shared clauses are supported" (NVIDIA HPC Compilers User's Guide
+!   26.9, Using OpenMP, item 2.6 Parallel Construct), "The distribute construct is supported within a teams construct." (item
+!   2.9.4), and the guide's own example of "nested parallelism in the target teams distribute construct" (a parallel loop inside
+!   it, with thread_limit recommended); item 2.20 says "nested teams or parallel regions in a target region are not supported",
+!   which could also be read as excluding this form; the guide's own example and NVHPC 26.9's correct run of this file are the
+!   reasons to read it as a second level of parallelism, and the program is legal by the specification either way
+!   (data/index/claims/nvidia-hpc-26.9-user-guide-openmp.txt)
+! - exploration (not result rows): num_threads(3), num_teams(2) on the
+!   teams, do simd, an
+!   allocatable o2 and an explicit map(tofrom: o2) all give sum= 0 on 25.11 and the right sum on 26.9
+! - same-compiler control: controls/nvhpc-distribute-parallel-num-threads-removed-control.f90 (one change from this file; correct on
+!   nvhpc (NVHPC 25.11); rows results/parity/nvc1/tuo.dp.jsonl, results/parity/nvc1/wt.dp.jsonl);
+!   controls/nvhpc-distribute-parallel-removed-control.f90 (one change from this file; correct on nvhpc (NVHPC 25.11); rows
+!   results/parity/nvc1/tuo.dp.jsonl, results/parity/nvc1/wt.dp.jsonl)
+! - other families: afar (AFAR 24.3.0), cce19 (CCE 19.0.0), cce20 (CCE 20.0.2), cce21 (CCE 21.0.3), cce21_4 (CCE 21.0.4), nvhpc269
+!   (NVHPC 26.9) run the file correctly (rows results/parity/nvc1/gate_abd.dp.jsonl, results/parity/nvc1/gate_abd.dp.m2.jsonl,
+!   results/parity/nvc1/gate_c.dp.jsonl, results/parity/nvc1/gate_c.dp.m2.jsonl, results/parity/nvc1/tuo.dp.jsonl,
+!   results/parity/nvc1/wt.dp.jsonl)
+! - gate and confirmer: 2 of 2 cells reproduce in all four environments (a-d; (c) on another node or GPU than (a); rows
+!   results/parity/nvc1/gate_abd.dp.jsonl, results/parity/nvc1/gate_abd.dp.m2.jsonl, results/parity/nvc1/gate_c.dp.jsonl,
+!   results/parity/nvc1/gate_c.dp.m2.jsonl, results/parity/nvc1/wt.dp.jsonl); campaign gate of the programs below: 2 cells, 2
+!   confirmed in the four environments (a-d; (c) on another node or GPU; rows
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.abd.127709.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.abd.127721.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.c.210952.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.c.210965.jsonl)
+! - programs (2): par-c1-nvhpc-nvhpc269:1098, par-c1-nvhpc-nvhpc269:1733
+! - legality: the rules (offload.engine.rules) and AFAR's flang front end accept this file and both controls
+!   (offload.engine.prerun.check on
+!   a Tuolumne compute node; results/parity/nvc1/prerun.dp.txt); AFAR 24.3.0 and CCE 19/20/21/21.0.4 compile and run all three
+!   correctly with HSA_XNACK 0 and 1 (results/parity/nvc1/tuo.dp.jsonl). NVHPC is the compiler under test and is not counted as a
+!   witness (26.9 runs the file correctly, 25.11 does not)
+program p
+  use omp_lib, only: omp_is_initial_device
+  implicit none
+  integer, parameter :: n = 32, m = 4
+  integer :: o2(n, m)
+  integer :: i, j, h
+  h = -1
+  o2 = 0
+  !$omp target map(tofrom: h)
+  !$omp teams
+  !$omp distribute
+  do i = 1, n
+    if (i == 1) h = merge(1, 0, omp_is_initial_device())
+    !$omp parallel num_threads(1)
+    !$omp do
+      do j = 1, m
+        o2(i, j) = i + j
+      end do
+    !$omp end do
+    !$omp end parallel
+  end do
+  !$omp end teams
+  !$omp end target
+  print '(a,i0,a,i0)', 'sum= ', sum(o2), ' h= ', h
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', merge(1, 0, h == 1), ' check=', merge('pass', 'fail', sum(o2) == 2432 .and. h == 0)
+end program p
+
+! site:
+! title: parallel num_threads inside distribute: writes lost (25.11)
+! summary: nvfortran 25.11 -mp=gpu appears to behave incorrectly on a worksharing loop in a parallel region with a num_threads
+! + clause nested in a distribute loop: the array it writes stays zero on the host. Without the num_threads clause, or without the
+! + nested parallel region, the result is right; NVHPC 26.9 is correct.
+! control: fuzz/controls/nvhpc-distribute-parallel-num-threads-removed-control.f90 one change from the finding; correct on nvhpc
+! control: fuzz/controls/nvhpc-distribute-parallel-removed-control.f90 one change from the finding; correct on nvhpc
+! end site

offload/_root/data/findings/fuzz/nvhpc-end-distribute-simd-rejected.f90

@@ -0,0 +1,70 @@
+! # Finding (parity-fuzz-s1): NVHPC: the end directive of a distribute simd construct is rejected ("Syntax error at or near
+! # identifier simd"); the construct without its end directive compiles and runs correctly
+!
+! - toolchains and modes that fail: nvhpc (NVHPC 25.11), nvhpc269 (NVHPC 26.9); modes: copy, managed; -O2
+! - build: nvfortran -mp=gpu -gpu=cc80 -gpu=mem:separate -O2
+! - failure: rejected
+! - observed: `NVFORTRAN-S-0034-Syntax error at or near identifier simd (<tmpdir>/nvhpc-end-distribute-simd-rejected.f90: 11)`;
+!   identical signature on 4 of 4 failing cells
+! - expected: compiles and prints `sum= 2080` with `check=pass`
+! - rule: "If directive-name-A is distribute then directive-name-B may be simd" (5.2 §17.3 p.342 l.17) names the composite
+!   distribute simd construct; the directive-name of its paired end directive is "end directive-name unless otherwise specified"
+!   (5.2 §3.1 p.49 l.14) and "For a loop-associated directive, the paired end directive is optional." (5.2 §3.1 p.52 l.26):
+!   `!$omp end distribute simd` is the construct's end directive, which may be written or left out
+! - vendor: "The distribute simd construct is treated as a distribute construct and is supported for GPU targets; valid
+!   supported distribute clauses are accepted; simd clauses are ignored." (NVIDIA HPC Compilers User's Guide 26.9, Using OpenMP,
+!   item 2.9.4; data/index/claims/nvidia-hpc-26.9-user-guide-openmp.txt)
+! - same-compiler control: controls/nvhpc-distribute-simd-no-end-directive-control.f90 (one change from this file; correct on nvhpc
+!   (NVHPC 25.11), nvhpc269 (NVHPC 26.9); rows results/parity/nvs1/tuo.ds.jsonl, results/parity/nvs1/wt.ds.jsonl);
+!   controls/nvhpc-distribute-end-distribute-control.f90 (one change from this file; correct on nvhpc (NVHPC 25.11), nvhpc269 (NVHPC
+!   26.9); rows results/parity/nvs1/tuo.ds.jsonl, results/parity/nvs1/wt.ds.jsonl)
+! - other families: afar (AFAR 24.3.0), cce19 (CCE 19.0.0), cce20 (CCE 20.0.2), cce21 (CCE 21.0.3), cce21_4 (CCE 21.0.4) run the
+!   file correctly (rows results/parity/nvs1/tuo.ds.jsonl)
+! - variants: files next to the reduction in results/parity/nvs1/red/, rows results/parity/nvs1/wt.ds.jsonl (both releases,
+!   separate and managed memory) and results/parity/nvs1/tuo.ds.jsonl: the combined teams distribute simd with its end directive
+!   (nvhpc-end-teams-distribute-simd-unmatched-variant.f90) is rejected with `NVFORTRAN-F-1225-Unmatched directive END - TEAMS
+!   DISTRIBUTE`; the combined target teams distribute simd with its end directive
+!   (nvhpc-end-target-teams-distribute-simd-variant.f90) compiles and is correct. The two s1 programs end their distribute simd
+!   loops with the end directive (fuzz_prog.f90 lines 75 and 90 of seeds 9906 and 8744, the lines the compiler names)
+! - gate and confirmer: 4 of 4 cells reproduce in all four environments (a-d; (c) on another node or GPU than (a); rows
+!   results/parity/nvs1/gate_abd.ds.jsonl, results/parity/nvs1/gate_abd.ds.m2.jsonl, results/parity/nvs1/gate_c.ds.jsonl,
+!   results/parity/nvs1/gate_c.ds.m2.jsonl, results/parity/nvs1/wt.ds.jsonl); campaign gate of the programs below: 4 cells, 4
+!   confirmed in the four environments (a-d; (c) on another node or GPU; rows
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.abd.2465893.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.abd.2476695.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.c.3354124.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.c.3482833.jsonl)
+! - programs (2): par-s1-nvhpc-nvhpc269:9906, par-s1-nvhpc-nvhpc269:8744; the same syntax error is in the stderr of seeds 2146,
+!   3062 and 6056 (`!$omp end distribute simd`) and the Unmatched directive message of the variant in those of 671 and 5847
+!   (`!$omp end teams distribute simd`), both releases, whose cells' first diagnostics are other rejections (an unrecognized
+!   declare directive, a syntax error at `:`, thread_limit on target), so they are not counted
+! - legality: the rules (offload.engine.rules) and AFAR's flang front end accept this file, its controls and the variants above
+!   (offload.engine.prerun.check on a Tuolumne compute node; results/parity/nvs1/prerun.ds.txt); AFAR 24.3.0 and CCE 19/20/21/21.0.4
+!   compile and run all of them correctly with HSA_XNACK 0 and 1 (results/parity/nvs1/tuo.ds.jsonl). NVHPC is the compiler under
+!   test and is not counted as a witness
+program p
+  implicit none
+  integer :: a(64), i
+  a = 0
+  !$omp target map(from: a)
+    !$omp teams
+      !$omp distribute simd
+      do i = 1, 64
+        a(i) = i
+      end do
+      !$omp end distribute simd
+    !$omp end teams
+  !$omp end target
+  print '(a,i0)', 'sum= ', sum(a)
+  print '(a,a)', 'RESULT ran_on_host=0 check=', merge('pass', 'fail', sum(a) == 2080)
+end program p
+
+! site:
+! title: end distribute simd: syntax error
+! summary: nvfortran -mp=gpu appears not to support the end directive of a distribute simd construct: `!$omp end distribute
+! + simd` stops the compile with a syntax error at `simd`, and `!$omp end teams distribute simd` with "Unmatched directive END -
+! + TEAMS DISTRIBUTE". The same construct without its end directive, or a distribute construct with its end directive, compiles
+! + and runs correctly.
+! control: fuzz/controls/nvhpc-distribute-simd-no-end-directive-control.f90 one change from the finding; correct on nvhpc, nvhpc269
+! control: fuzz/controls/nvhpc-distribute-end-distribute-control.f90 one change from the finding; correct on nvhpc, nvhpc269
+! end site

offload/_root/data/findings/fuzz/nvhpc-loop-character-achar-unsupported.f90

@@ -0,0 +1,75 @@
+! # Finding (parity-fuzz-s1): NVHPC: a character value computed in the region (achar, a concatenation) assigned to a character
+! # array element inside a loop construct of a target region fails to translate ("Character local variable unsupported on
+! # device"); the same assignment in a distribute construct compiles and runs correctly
+!
+! - toolchains and modes that fail: nvhpc (NVHPC 25.11), nvhpc269 (NVHPC 26.9); modes: copy, managed; -O2
+! - build: nvfortran -mp=gpu -gpu=cc80 -gpu=mem:separate -O2
+! - failure: ice
+! - observed: `NVFORTRAN-F-0155-Compiler failed to translate accelerator region (see -Minfo messages): Character local variable
+!   unsupported on device (<tmpdir>/nvhpc`; identical signature on 4 of 4 failing cells
+! - expected: compiles and prints `s= 1160` with `check=pass`
+! - rule: "A loop construct specifies that the logical iterations of the associated loops may execute concurrently and permits
+!   the encountering threads to execute the loop accordingly." (5.2 §11.7 p.257 l.8-9); the loop body is a character assignment,
+!   which no restriction of the construct excludes
+! - vendor: "The private, bind, and collapse clauses are supported" on the loop construct (NVIDIA HPC Compilers User's Guide
+!   26.9, Using OpenMP, item 2.9.5; data/index/claims/nvidia-hpc-26.9-user-guide-openmp.txt); the guide names no character limit
+! - same-compiler control: controls/nvhpc-loop-character-distribute-control.f90 (one change from this file; correct on nvhpc
+!   (NVHPC 25.11), nvhpc269 (NVHPC 26.9); rows results/parity/nvs1/tuo.cl.jsonl, results/parity/nvs1/wt.cl.jsonl);
+!   controls/nvhpc-loop-character-array-value-control.f90 (the value copied from a mapped character array instead of computed:
+!   four edits from this file, the array, its initialization, its map clause and the assignment; correct on nvhpc (NVHPC 25.11),
+!   nvhpc269 (NVHPC 26.9); rows results/parity/nvs1/tuo.cl.jsonl, results/parity/nvs1/wt.cl.jsonl)
+! - other families: afar (AFAR 24.3.0), cce20 (CCE 20.0.2), cce21 (CCE 21.0.3), cce21_4 (CCE 21.0.4) run the file correctly (rows
+!   results/parity/nvs1/tuo.cl.jsonl); cce19 (CCE 19.0.0) fail it another way, e.g. `ftn-7032 ftn: ERROR P, File =
+!   ../../nvhpc-loop-character-achar-unsupported.f90, Line = 10`
+! - variants: files next to the reduction in results/parity/nvs1/red/, rows results/parity/nvs1/wt.cl.jsonl (both releases,
+!   separate and managed memory) and results/parity/nvs1/tuo.cl.jsonl: the seed's concatenation `achar(...) // xc(i)(2:4)` in a
+!   loop construct of a target parallel region (nvhpc-loop-character-concatenation-target-parallel-variant.f90) fails the same
+!   way; the same concatenation in a do construct of the target parallel region compiles
+!   (nvhpc-loop-character-concatenation-do-control.f90) but its run does not end on either release, the implicit barrier of a
+!   worksharing loop in a combined target parallel construct (the c1 finding nvhpc-target-parallel-single-hang.f90), so it is
+!   not a control of this finding. A substring copy `o2(i)(2:4) = xc(i)(2:4)` in the loop construct compiles (exploration)
+! - gate and confirmer: 4 of 4 cells reproduce in all four environments (a-d; (c) on another node or GPU than (a); rows
+!   results/parity/nvs1/gate_abd.cl.jsonl, results/parity/nvs1/gate_abd.cl.m2.jsonl, results/parity/nvs1/gate_c.cl.jsonl,
+!   results/parity/nvs1/gate_c.cl.m2.jsonl, results/parity/nvs1/wt.cl.jsonl); campaign gate of the programs below: 2 cells, 2
+!   confirmed in the four environments (a-d; (c) on another node or GPU; rows
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.abd.2465893.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.abd.2476695.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.c.3354124.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.c.3482833.jsonl)
+! - programs (1): par-s1-nvhpc-nvhpc269:2564
+! - legality: the rules (offload.engine.rules) and AFAR's flang front end accept this file, its controls and the variants above
+!   (offload.engine.prerun.check on a Tuolumne compute node; results/parity/nvs1/prerun.cl.txt); AFAR 24.3.0 and CCE 20/21/21.0.4
+!   compile and run this file and its controls correctly with HSA_XNACK 0 and 1 (results/parity/nvs1/tuo.cl.jsonl); CCE 19
+!   rejects character data in target regions ("Unsupported OpenMP construct Fortran character"), its own documented limit
+!   (afar-cce19-character-defaultmap.f90). NVHPC is the compiler under test and is not counted as a witness
+program p
+  implicit none
+  integer, parameter :: n = 16
+  character(len=4) :: o2(n)
+  integer :: i, s
+  o2 = ' '
+  !$omp target teams map(from: o2)
+    !$omp loop
+    do i = 1, n
+      o2(i) = achar(64 + i)
+    end do
+    !$omp end loop
+  !$omp end target teams
+  s = 0
+  do i = 1, n
+    s = s + ichar(o2(i)(1:1))
+  end do
+  print '(a,i0)', 's= ', s
+  print '(a,a)', 'RESULT ran_on_host=0 check=', merge('pass', 'fail', s == 16 * 64 + 136)
+end program p
+
+! site:
+! title: character value in a loop construct: unsupported
+! summary: nvfortran -mp=gpu appears not to support assigning a character value computed in the region (achar, a concatenation)
+! + to a character array element inside a loop construct of a target region: the compile stops with "Character local variable
+! + unsupported on device". The same assignment in a distribute construct, or the copy of a mapped character element in the loop
+! + construct, compiles and runs correctly.
+! control: fuzz/controls/nvhpc-loop-character-distribute-control.f90 one change from the finding; correct on nvhpc, nvhpc269
+! control: fuzz/controls/nvhpc-loop-character-array-value-control.f90 the value copied from a mapped character array (four
+! + edits from the finding); correct on nvhpc, nvhpc269
+! end site

offload/_root/data/findings/fuzz/nvhpc-map-always-after-map-to-not-copied-back.f90

@@ -0,0 +1,70 @@
+! # Finding (parity-fuzz-c1): NVHPC: a map clause with the always modifier (tofrom or from) that follows a map(to:) clause on the
+! # same target directive is not copied back; its list items keep their host values
+!
+! - toolchains and modes that fail: nvhpc (NVHPC 25.11), nvhpc269 (NVHPC 26.9); modes: copy, managed; -O2
+! - build: nvfortran -mp=gpu -gpu=cc80 -gpu=mem:separate -O2
+! - failure: wrong_answer (check=fail)
+! - observed: `r= 0 h= 0` with `check=fail`; identical signature on 4 of 4 failing cells
+! - expected: compiles and prints `r= 5 h= 0` with `check=pass`
+! - rule: on exit from the region, "If the reference count of the corresponding list item is one or if the always map-type-modifier
+!   is specified, and if the map-type is from or tofrom, the original list item is updated as if the list item appeared in a from
+!   clause on a target update directive." (5.2 §5.8.3 p.154 l.2-5): r is in a tofrom map with the always modifier and its reference
+!   count is one, so the device value (a(5) = 5) must reach the host either way; the order of the map clauses on the directive
+!   carries no meaning
+! - vendor: "The map([[mapmod[,]...] maptype:] datalist) clause is supported. Of the map-type-modifiers, always is supported, close
+!   is ignored, and mapper(mapid) is not supported." (NVIDIA HPC Compilers User's Guide 26.9, Using OpenMP, item 2.19.7;
+!   data/index/claims/nvidia-hpc-26.9-user-guide-openmp.txt)
+! - variants: files next to the reduction in results/parity/nvc1/red/, rows results/parity/nvc1/wt.al.jsonl (both releases, separate
+!   and managed memory) and results/parity/nvc1/tuo.al.jsonl (AFAR and CCE correct on all of them): map(always, from: r)
+!   (nvhpc-map-always-from-after-map-to-variant.f90), the always clause separated from the map(to:) clause by another map clause
+!   (nvhpc-map-always-after-map-to-separated-variant.f90), two list items in the always clause, both lost
+!   (nvhpc-map-always-after-map-to-two-items-variant.f90), and the write inside a parallel worksharing loop
+!   (nvhpc-map-always-after-map-to-parallel-do-variant.f90) fail on both releases too
+! - exploration (not result rows): the items of the always clause do arrive
+!   on the device (a
+!   mapped array summed there, a scalar read there); a preceding map(from:) or map(tofrom:) clause does not trigger the loss, a
+!   preceding map(always, to:) clause does; scalars in map(always, tofrom:) with no preceding map(to:) clause are right with and
+!   without teams or parallel regions. In c1 program 2019 the three kernels' reductions and arrays were wrong this way (a teams
+!   reduction variable in map(always, tofrom:) after map(always, to:), the array of the same clause read as zeros); with the always
+!   modifiers removed, or with the always clauses written first, the program prints its expected checksum on both releases
+! - same-compiler control: controls/nvhpc-map-always-removed-control.f90 (one change from this file; correct on nvhpc (NVHPC 25.11),
+!   nvhpc269 (NVHPC 26.9); rows results/parity/nvc1/tuo.al.jsonl, results/parity/nvc1/wt.al.jsonl);
+!   controls/nvhpc-map-always-first-control.f90 (one change from this file; correct on nvhpc (NVHPC 25.11), nvhpc269 (NVHPC 26.9);
+!   rows results/parity/nvc1/tuo.al.jsonl, results/parity/nvc1/wt.al.jsonl)
+! - other families: afar (AFAR 24.3.0), cce19 (CCE 19.0.0), cce20 (CCE 20.0.2), cce21 (CCE 21.0.3), cce21_4 (CCE 21.0.4) run the
+!   file correctly (rows results/parity/nvc1/tuo.al.jsonl)
+! - gate and confirmer: 4 of 4 cells reproduce in all four environments (a-d; (c) on another node or GPU than (a); rows
+!   results/parity/nvc1/gate_abd.al.jsonl, results/parity/nvc1/gate_abd.al.m2.jsonl, results/parity/nvc1/gate_c.al.jsonl,
+!   results/parity/nvc1/gate_c.al.m2.jsonl, results/parity/nvc1/wt.al.jsonl); campaign gate of the programs below: 2 cells, 2
+!   confirmed in the four environments (a-d; (c) on another node or GPU; rows
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.abd.127709.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.c.210965.jsonl)
+! - programs (1): par-c1-nvhpc-nvhpc269:2019
+! - legality: the rules (offload.engine.rules) and AFAR's flang front end accept this file, both controls and the variants
+!   (offload.engine.prerun.check on a Tuolumne compute node; results/parity/nvc1/prerun.al.txt); AFAR 24.3.0 and CCE 19/20/21/21.0.4
+!   compile and run all of them correctly with HSA_XNACK 0 and 1 (results/parity/nvc1/tuo.al.jsonl). NVHPC is the compiler under
+!   test and is not counted as a witness
+program p
+  use omp_lib, only: omp_is_initial_device
+  implicit none
+  integer :: a(64)
+  integer :: i, r, h
+  a = [(i, i = 1, 64)]
+  r = 0
+  h = -1
+  !$omp target map(to: a) map(always, tofrom: r) map(tofrom: h)
+    h = merge(1, 0, omp_is_initial_device())
+    r = a(5)
+  !$omp end target
+  print '(a,i0,a,i0)', 'r= ', r, ' h= ', h
+  print '(a,i0,a,a)', 'RESULT ran_on_host=', merge(1, 0, h == 1), ' check=', merge('pass', 'fail', r == 5 .and. h == 0)
+end program p
+
+! site:
+! title: map(always, tofrom:) after map(to:): not copied back
+! summary: nvfortran -mp=gpu appears to behave incorrectly on a map clause with the always modifier (tofrom or from) that follows a
+! + map(to:) clause on the same target directive: its list items are not copied back and keep their host values. Without the
+! + modifier, or with the always clause written before the map(to:) clause, the result is right.
+! control: fuzz/controls/nvhpc-map-always-removed-control.f90 one change from the finding; correct on nvhpc, nvhpc269
+! control: fuzz/controls/nvhpc-map-always-first-control.f90 one change from the finding; correct on nvhpc, nvhpc269
+! end site

offload/_root/data/findings/fuzz/nvhpc-num-threads-reduction-identity-lost.f90

@@ -0,0 +1,54 @@
+! # Finding (parity-fuzz-c1): NVHPC: a reduction(*) (also max, iand) on the worksharing loop of a parallel region with
+! # num_threads(2) in a target region gives 0
+!
+! - toolchains and modes that fail: nvhpc (NVHPC 25.11), nvhpc269 (NVHPC 26.9); modes: copy, managed; -O2
+! - build: nvfortran -mp=gpu -gpu=cc80 -gpu=mem:separate -O2
+! - failure: wrong_answer (check=fail)
+! - observed: `r= 0` with `check=fail`; identical signature on 4 of 4 failing cells
+! - expected: compiles and prints `r= 768` with `check=pass`
+! - rule: "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); the initializer of * is 1
+!   (Table 5.2), so r is 3 times 2**8 = 768 whatever the number of threads
+! - vendor: on GPU targets the parallel construct supports "The num_threads, default, private, firstprivate, and shared clauses",
+!   and "The reduction clause is supported. The optional modifier is not supported." (NVIDIA HPC Compilers User's Guide 26.9, Using
+!   OpenMP, items 2.6 and 2.19.5; data/index/claims/nvidia-hpc-26.9-user-guide-openmp.txt)
+! - same-compiler control: controls/nvhpc-num-threads-removed-control.f90 (one change from this file; correct on nvhpc (NVHPC
+!   25.11), nvhpc269 (NVHPC 26.9); rows results/parity/nvc1/tuo.nt.jsonl, results/parity/nvc1/wt.nt.jsonl)
+! - other families: afar (AFAR 24.3.0), cce19 (CCE 19.0.0), cce20 (CCE 20.0.2), cce21 (CCE 21.0.3), cce21_4 (CCE 21.0.4) run the
+!   file correctly (rows results/parity/nvc1/tuo.nt.jsonl)
+! - variants: files next to the reduction in results/parity/nvc1/red/, rows results/parity/nvc1/wt.nt.jsonl (both releases, separate
+!   and managed memory) and results/parity/nvc1/tuo.nt.jsonl: reduction(max: r) (nvhpc-num-threads-reduction-max-variant.f90) and
+!   reduction(iand: r) (nvhpc-num-threads-reduction-iand-variant.f90) print `r= 0` too, as does the same loop written as target,
+!   parallel num_threads(2) and do (nvhpc-num-threads-split-variant.f90); reduction(+: r) with num_threads(2)
+!   (nvhpc-num-threads-reduction-sum-variant.f90) is correct. The reduction identifiers whose initializer is not 0 lose their result
+! - gate and confirmer: 4 of 4 cells reproduce in all four environments (a-d; (c) on another node or GPU than (a); rows
+!   results/parity/nvc1/gate_abd.nt.jsonl, results/parity/nvc1/gate_abd.nt.m2.jsonl, results/parity/nvc1/gate_c.nt.jsonl,
+!   results/parity/nvc1/gate_c.nt.m2.jsonl, results/parity/nvc1/wt.nt.jsonl); campaign gate of the programs below: 2 cells, 2
+!   confirmed in the four environments (a-d; (c) on another node or GPU; rows
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.abd.127721.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.c.210952.jsonl)
+! - programs (1): par-c1-nvhpc-nvhpc269:2123
+! - legality: the rules (offload.engine.rules) and AFAR's flang front end accept this file, its control and the variants above
+!   (offload.engine.prerun.check on a Tuolumne compute node; results/parity/nvc1/prerun.nt.txt); AFAR 24.3.0 and CCE 19/20/21/21.0.4
+!   compile and run all of them correctly with HSA_XNACK 0 and 1 (results/parity/nvc1/tuo.nt.jsonl). NVHPC is the compiler under
+!   test and is not counted as a witness
+program p
+  implicit none
+  integer :: r, i
+  r = 3
+  !$omp target parallel do map(tofrom: r) num_threads(2) reduction(*: r)
+  do i = 1, 8
+    r = r * 2
+  end do
+  !$omp end target parallel do
+  print '(a,i0)', 'r= ', r
+  print '(a,a)', 'RESULT ran_on_host=0 check=', merge('pass', 'fail', r == 768)
+end program p
+
+! site:
+! title: num_threads with a * reduction gives 0
+! summary: nvfortran -mp=gpu appears to behave incorrectly on a worksharing-loop reduction with *, max or iand in a parallel region
+! + with num_threads(2) inside a target region: the result is 0. Without num_threads, or with a + reduction, the result is right.
+! control: fuzz/controls/nvhpc-num-threads-removed-control.f90 one change from the finding; correct on nvhpc, nvhpc269
+! end site

offload/_root/data/findings/fuzz/nvhpc-target-parallel-firstprivate-translate-failure.f90

@@ -0,0 +1,66 @@
+! # Finding (parity-fuzz-c1): NVHPC: nvfortran fails with "Compiler failed to translate OpenMP region" on firstprivate on a target
+! # parallel construct that contains a worksharing loop
+!
+! - toolchains and modes that fail: nvhpc (NVHPC 25.11), nvhpc269 (NVHPC 26.9); modes: copy, managed; -O2
+! - build: nvfortran -mp=gpu -gpu=cc80 -gpu=mem:separate -O2
+! - failure: compiler failure (NVFORTRAN-F-0155, exit status 2 at compile time); the harness files it as rejected, the index as
+!   ice, as the C sibling nvhpc-c-parallel-for-firstprivate-in-target.c does
+! - observed: `NVFORTRAN-F-0155-Compiler failed to translate OpenMP region
+!   (<tmpdir>/nvhpc-target-parallel-firstprivate-translate-failure.f90: 6)`; identical signature on 4 of 4 failing cells
+! - expected: compiles and prints `suma= 2272` with `check=pass`
+! - rule: the target construct's clauses include firstprivate (5.2 §13.8 p.284 l.4-6), and "The semantics of the combined constructs
+!   are identical to that of explicitly specifying the first construct containing one instance of the second construct and no other
+!   statements." (5.2 §17.4 p.343 l.7-8): the program is target firstprivate(k) containing a parallel region with a worksharing
+!   loop, which nvfortran compiles (variants)
+! - vendor: "The if, private, firstprivate, is_device_ptr, and nowait clauses are supported" on the target construct and "Combined
+!   constructs are supported to the extent that the component constructs are themselves supported." (NVIDIA HPC Compilers User's
+!   Guide 26.9, Using OpenMP, items 2.12.5 and 2.13; data/index/claims/nvidia-hpc-26.9-user-guide-openmp.txt). The C sibling,
+!   firstprivate on a parallel for in a target region, is nvhpc-c-parallel-for-firstprivate-in-target.c (the same message)
+! - same-compiler control: controls/nvhpc-target-parallel-firstprivate-dropped-control.f90 (one change from this file; correct on
+!   nvhpc (NVHPC 25.11), nvhpc269 (NVHPC 26.9); rows results/parity/nvc1/tuo.fp2.jsonl, results/parity/nvc1/wt.fp2.jsonl)
+! - other families: afar (AFAR 24.3.0), cce19 (CCE 19.0.0), cce20 (CCE 20.0.2), cce21 (CCE 21.0.3), cce21_4 (CCE 21.0.4) run the
+!   file correctly (rows results/parity/nvc1/tuo.fp2.jsonl)
+! - variants: files next to the reduction in results/parity/nvc1/red/, rows results/parity/nvc1/wt.fp2.jsonl (both releases,
+!   separate and managed memory) and results/parity/nvc1/tuo.fp2.jsonl: the same loop under target firstprivate(k) with a separate
+!   parallel construct (nvhpc-target-firstprivate-split-variant.f90) and as target parallel do firstprivate(k)
+!   (nvhpc-target-parallel-do-firstprivate-variant.f90) compile and are correct on NVHPC. The fuzz program (seed 2207) also has a
+!   critical construct in the region, which the guide documents as unsupported on GPU targets; with firstprivate(p1) removed
+!   nvfortran reports that error instead (an exploration compile, not a recorded row), so the translation failure comes first
+! - gate and confirmer: 4 of 4 cells reproduce in all four environments (a-d; (c) on another node or GPU than (a); rows
+!   results/parity/nvc1/gate_abd.fp2.jsonl, results/parity/nvc1/gate_abd.fp2.m2.jsonl, results/parity/nvc1/gate_c.fp2.jsonl,
+!   results/parity/nvc1/gate_c.fp2.m2.jsonl, results/parity/nvc1/wt.fp2.jsonl); campaign gate of the programs below: 2 cells, 2
+!   confirmed in the four environments (a-d; (c) on another node or GPU; rows
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.abd.127709.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.abd.127721.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.c.210952.jsonl,
+!   results/parity/wingtip/results/parity/gate/fuzz/reruns/wingtip.c.210965.jsonl)
+! - programs (1): par-c1-nvhpc-nvhpc269:2207
+! - legality: the rules (offload.engine.rules) and AFAR's flang front end accept this file, its control and the variants above
+!   (offload.engine.prerun.check on a Tuolumne compute node; results/parity/nvc1/prerun.fp2.txt); AFAR 24.3.0 and CCE
+!   19/20/21/21.0.4
+!   compile and run it correctly with HSA_XNACK 0 and 1 (results/parity/nvc1/tuo.fp2.jsonl). NVHPC is the compiler under test and is
+!   not counted as a witness
+program p
+  implicit none
+  integer :: a(64), i, k
+  a = 0
+  k = 3
+  !$omp target parallel map(tofrom: a) firstprivate(k)
+    !$omp do
+    do i = 1, 64
+      a(i) = i + k
+    end do
+    !$omp end do nowait
+  !$omp end target parallel
+  print '(a,i0)', 'suma= ', sum(a)
+  print '(a,a)', 'RESULT ran_on_host=0 check=', merge('pass', 'fail', sum(a) == 2080 + 64 * 3)
+end program p
+
+! site:
+! title: firstprivate on target parallel with a do loop: translation failure
+! summary: nvfortran -mp=gpu appears to behave incorrectly on a target parallel construct with firstprivate that contains a
+! + worksharing loop: the compile stops with "Compiler failed to translate OpenMP region". Without firstprivate, or with a separate
+! + parallel construct, it compiles and runs correctly.
+! control: fuzz/controls/nvhpc-target-parallel-firstprivate-dropped-control.f90 one change from the finding; correct on nvhpc,
+! + nvhpc269
+! end site