offtarget 0.1.0__py3-none-any.whl

offload/_root/data/findings/afar-xnack1-present-not-enforced.f90

@@ -0,0 +1,36 @@
+! (copy mode for the whole catalog): AFAR does not perform the
+! runtime error termination of the present map-type-modifier at
+! HSA_XNACK=1 (unified memory).
+! a was never mapped, so on entry to the region it is not present and
+! "runtime error termination is performed" (5.2 §5.8.3 p.152); the
+! program has no requires directive, so unified memory does not change
+! the rule.
+! Expected: an error termination before the end (no "reached the end").
+! Observed (tuolumne, MI300A, 2026-10-22, 3 runs each, -O2,
+! OMP_TARGET_OFFLOAD=mandatory):
+! - AFAR amdflang 24.0.0git at HSA_XNACK=1: "reached the end: b1= 2" (the
+!   region runs on the shared data); at HSA_XNACK=0: "omptarget message:
+!   device mapping required by 'present' map type modifier does not exist"
+!   and error termination, as required. AFAR amdclang (C programs) the same.
+! - CCE 19.0.0, 20.0.2, 21.0.3: error termination in both modes ("Variable
+!   not found in present table").
+! The catalog's map.present negative probes (Fortran and C, 5.2 and 6.0)
+! read wrong at HSA_XNACK=1 and correct at HSA_XNACK=0 on AFAR.
+! AFAR: amdflang -fopenmp --offload-arch=gfx942 -O2
+! Run:  OMP_TARGET_OFFLOAD=mandatory HSA_XNACK=1 ./a.out
+program p
+  implicit none
+  integer :: a(64), b(64)
+  a = 1
+  b = 0
+  !$omp target map(present, to: a) map(from: b)
+    b = a + 1
+  !$omp end target
+  print *, 'reached the end: b1=', b(1)
+end program p
+! 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-xnack1-present-not-enforced-control.f90 run at HSA_XNACK=0
+! same_as: afar-xnack1-target-is-present
+! end site

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

@@ -0,0 +1,47 @@
+! AFAR reports nothing present in the device data
+! environment at HSA_XNACK=1 (unified memory).
+! After target enter data map(to: a), a has corresponding storage in the
+! device data environment, so omp_target_is_present must return true
+! (5.2 §18.8.3 p.389: "returns true if ... ptr refers to storage that has
+! corresponding storage in the device data environment"); after target
+! exit data map(release: a) it must return false. The program has no
+! requires directive.
+! 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 amdflang 24.0.0git at HSA_XNACK=1: present= 0 after enter data;
+!   at HSA_XNACK=0: present= 1, as required. AFAR amdclang the same (C
+!   reproducer: afar-c-xnack1-target-is-present.c).
+! - CCE 19.0.0, 20.0.2, 21.0.3: present= 1 / 0 in both modes.
+! The catalog's copy-mode programs skip their presence checks at
+! HSA_XNACK=1; run with the presence checks at HSA_XNACK=1
+! (tools/campaigns/presence_x1.py, tests/data/presence_x1_summary.json) every one of
+! them fails on AFAR (Fortran and C map alloc/delete/release, target data,
+! target enter/exit data, map iterator) and passes on CCE except the C
+! map.delete programs (cce-c-map-delete-refcount.c). Those AFAR cells are
+! correct at HSA_XNACK=0 only (portable verdict x0_only): 31 cells (19
+! Fortran, 12 C; with C map.iterator and transparent 34 presence cells)
+! that are ONE bug counted once per feature. The 5.2 basis:
+! entering a map creates a corresponding storage block with a reference
+! count even when it shares storage with the original (5.2 §5.8.3 p.153),
+! and the routine reports that block (§18.8.3 p.389).
+! AFAR: amdflang -fopenmp --offload-arch=gfx942 -O2
+! Run:  OMP_TARGET_OFFLOAD=mandatory HSA_XNACK=1 ./a.out
+program p
+  use omp_lib
+  use, intrinsic :: iso_c_binding, only: c_loc
+  implicit none
+  integer, target :: a(64)
+  integer :: d
+  a = 1
+  d = omp_get_default_device()
+  !$omp target enter data map(to: a)
+  print *, 'after enter data: present=', omp_target_is_present(c_loc(a), d)
+  !$omp target exit data map(release: a)
+  print *, 'after exit data: present=', omp_target_is_present(c_loc(a), d)
+end program p
+! 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-xnack1-target-is-present-control.f90 run at HSA_XNACK=0
+! end site

offload/_root/data/findings/apps/afar-cce-teams-private-array-nested-parallel-wrong.f90

@@ -0,0 +1,100 @@
+! # AFAR and CCE: an array private to each team, written by the threads of a nested parallel do, loses the writes
+!
+! (from the application corpus, PRK Fortran transpose-openmp-target, tile size 32, fails its
+! own check on AFAR and every CCE; the widened catalog program omp52-w-teams-private-array-parallel).
+! Compile: AFAR `amdflang -fopenmp --offload-arch=gfx942` (gfx90a on MI250X); CCE `ftn -fopenmp` after
+! `module load cce/<v> craype-accel-amd-gfx942 rocm/<r>; module unload cray-mpich`; NVHPC
+! `nvfortran -mp=gpu -gpu=cc80 -gpu=mem:separate|managed`; all at -O2; run with OMP_TARGET_OFFLOAD=mandatory.
+! Expected: bad= 0 dev= 1 b(1:4)= 9 7 5 3
+!
+! Observed (2026-10-25; MI300A at HSA_XNACK 1 and 0, MI250X at HSA_XNACK 0, A100 separate and managed):
+! - AFAR 24.0.0git (drop 24.3.0): bad= 64 dev= 1 b(1:4)= 1 1 1 1 (MI300A both modes, MI250X)
+! - CCE 19.0.0 and 20.0.2: bad= 64 dev= 1 b(1:4)= 1 1 1 1 (MI300A both modes, MI250X)
+! - CCE 21.0.3: bad= 63 dev= 1 b(1:4)= 1 3 5 7 (MI300A both modes, MI250X)
+! - NVHPC 25.11 and 26.9: bad= 0 (separate and managed memory): the other family that passes
+! The values read back are not the team's: b = 1 means t(3-j) = 0.
+!
+! Logs: data/reports/apps/.
+! Controls (data/findings/apps/controls/, same compilers and modes):
+! - teams-private-array-seq.f90 (the same loops without the two parallel do directives, so the team's initial
+!   thread alone writes and reads t): bad= 0 on AFAR and CCE 19/20/21.
+! - teams-private-array-shared.f90 (the same nested parallel do loops, the scratch array mapped and indexed by
+!   the team's iteration instead of private): bad= 0 on AFAR and CCE 19/20/21.
+! - teams-private-array-write-par.f90 (only the writing loop parallel): wrong on AFAR and every CCE, as above.
+! - teams-private-array-read-par.f90 (only the reading loop parallel): AFAR wrong, CCE 19/20/21 correct.
+! - teams-private-array-split.f90 (`target teams private(t, j)` with a separate `distribute`): AFAR correct,
+!   CCE 19/20/21 wrong as above.
+! So both families lose writes to the team's copy made by the threads of the nested parallel region (they
+! write copies of their own); AFAR also reads copies of its own, but only with the clause on the combined
+! construct. NVHPC is correct on all six programs.
+!
+! Basis (OpenMP 5.2):
+! - §17.2 p.340 l.1-2: "The effect of the private clause is as if it is applied only to the innermost leaf
+!   construct that permits it." Here that is distribute (and teams in the split control).
+! - §5.3 p.105 l.21-30: "Each task that references a privatized list item in any statement in the construct
+!   receives at least one new list item if the construct has one or more associated loops ... Inside the
+!   construct, all references to the original list item are replaced by references to a new list item
+!   received by the task ... within the same logical iteration of the loops, the same new list item replaces
+!   all references to the original list item." The initial task of each team executes the iteration jt, so
+!   one t serves the whole iteration.
+! - §5.1.1 p.99 l.13-16: "Rules for variables with implicitly determined data-sharing attributes are as
+!   follows: ... In a parallel construct, if no default clause is present, these variables are shared." t
+!   has no clause on the parallel do, so it is shared there.
+! - §5.4.2 p.110 l.8-10: "The shared clause declares one or more list items to be shared by tasks generated
+!   by the construct on which it appears. All references to a list item within a task refer to the storage
+!   area of the original variable at the point the directive was encountered." At the parallel directive,
+!   t is the team's (iteration's) new list item, so the threads write and read that storage.
+! - §1.4.1 p.27 l.30-35 (memory model): "A private variable in a task region that subsequently generates an
+!   inner nested parallel region is permitted to be made shared for implicit tasks in the inner parallel
+!   region. ... Any other access by one task to the private variables of another task results in
+!   unspecified behavior." This is the access here: the team task's private t, shared by the implicit tasks of
+!   the nested parallel regions.
+! - §10.2 p.230 l.12-13: "When a thread encounters a teams construct, a league of teams is created. Each team
+!   is an initial team, and the initial thread in each team executes the teams region."
+! Race-free: each thread of the first parallel do writes its own t(j); the loop ends with an implied barrier
+! (§11 p.240 l.5-7: "an implied barrier exists at the end of the worksharing region, unless a nowait clause
+! is specified") before the second parallel do reads t(3-j); b(jt+j) is written once; dev is written once,
+! by the initial thread of the team with jt = 1. j is private (the parallel do's loop variable is
+! predetermined private, §5.1.1; teams-level j is listed private). Legality was read against the spec; no
+! compiler under test, gfortran or gcc is a legality witness.
+!
+! Workaround in application code: give the scratch array a team dimension and map it (the shared control), or
+! keep the scratch private to the parallel loop's own iterations; the PRK transpose tile size 1 run (no
+! team-private tile) is correct everywhere.
+program teams_private_array_nested_parallel
+  use omp_lib, only: omp_is_initial_device
+  implicit none
+  integer, parameter :: n = 64
+  integer :: a(n), b(n), t(0:3), i, j, jt, bad, dev
+  do i = 1, n
+    a(i) = i
+  end do
+  b = 0
+  dev = -1
+  !$omp target teams distribute private(t, j) map(to: a) map(from: b) map(tofrom: dev)
+  do jt = 1, n, 4
+    !$omp parallel do
+    do j = 0, 3
+      t(j) = a(jt + j)
+    end do
+    !$omp end parallel do
+    !$omp parallel do
+    do j = 0, 3
+      b(jt + j) = 2*t(3 - j) + 1
+    end do
+    !$omp end parallel do
+    if (jt == 1) dev = merge(0, 1, omp_is_initial_device())
+  end do
+  !$omp end target teams distribute
+  bad = 0
+  do i = 1, n
+    if (b(i) /= 2*(2*(4*((i - 1)/4) + 1) + 3 - i) + 1) bad = bad + 1
+  end do
+  print '(a,i0,a,i0,a,4(1x,i0))', 'bad= ', bad, ' dev= ', dev, ' b(1:4)=', b(1:4)
+end program teams_private_array_nested_parallel
+! site:
+! title: ftn: an array private to target teams distribute and shared by a nested parallel do loses the parallel region's writes
+! control: ../vendor/checks/src/afar/control/afar-cce-teams-private-array-nested-parallel-wrong-control.f90 the same loops
+! + without the two
+! + parallel do directives (each team's initial thread runs them)
+! end site

offload/_root/data/findings/apps/cce20-device-link-infer-address-spaces-crash.f90

@@ -0,0 +1,159 @@
+! # CCE 20: device link crash in "Infer address spaces" (MFC's m_cbc kernel, reduced)
+!
+! MFC's OpenMP and OpenACC solvers do not link on CCE 20.0.2: lld (the device LTO link) crashes in
+! "Infer address spaces" on the kernel at m_cbc.fpp:597 (s_cbc$m_cbc_$ck_L597_13), with
+! "malloc_consolidate(): unaligned fastbin chunk detected". Reduced from MFC's preprocessed sources
+! (the kernel, then m_compute_cbc's routines it calls) to this program.
+! Compile: CCE `ftn -fopenmp -O2` after `module load cce/20.0.2 craype-accel-amd-gfx942 rocm/6.4.3;
+! module unload cray-mpich` (gfx90a: craype-accel-amd-gfx90a); AFAR `amdflang -fopenmp --offload-arch=gfx942`;
+! NVHPC `nvfortran -mp=gpu -gpu=cc80 -gpu=mem:separate|managed`; run with OMP_TARGET_OFFLOAD=mandatory.
+! Expected: builds; prints bad= 0 out(:,1)=    0.00    9.50   11.00    6.00    8.00
+!
+! Observed (2026-10-25):
+! - CCE 20.0.2 (gfx942 and gfx90a): the link fails: lld aborts, "Running pass 'Infer address spaces' on
+!   function '@"cce20_infer_address_spaces_$ck_L..._3"'" (3 of 3 builds on gfx942, log). Under
+!   valgrind, MFC's own kernel shows the cause: an invalid read in
+!   llvm::RecursivelyDeleteTriviallyDeadInstructions called from
+!   InferAddressSpacesImpl::rewriteWithNewAddressSpaces (a use after free), before the abort.
+!   At -O0 CCE 20 builds it and prints bad= 0.
+! - CCE 19.0.0 and 21.0.3, AFAR 24.0.0git (drop 24.3.0): builds, bad= 0 (MI300A at HSA_XNACK 1 and 0; MI250X).
+! - NVHPC 25.11 and 26.9 (A100, separate and managed memory): bad= 0.
+!
+! What it needs (controls in apps/controls/, all link and print bad= 0 on CCE 20):
+! - cbc-inline.f90: the same program without the !DIR$ INLINENEVER line (CCE inlines the two helpers when it
+!   compiles the file): links. INLINENEVER is a Cray compiler directive (a comment to other compilers); with
+!   it the helpers are inlined only by the device link's LTO; with -h ipa0 instead of the directive this
+!   control crashes too. In MFC the trigger is the fypp line markers of the generated m_compute_cbc: with them
+!   CCE emits different device code for its routines (smaller, the helpers' pointer arguments without
+!   noalias) and the reduced m_cbc kernel crashes the link; without them it links
+!   (data/reports/apps/mfc-device-link.txt). INLINENEVER is this program's way to reach the crash, not a
+!   claim about what the markers do.
+! - cbc-integers.f90: the index ranges as plain integer module variables instead of components of the
+!   declare target derived-type variable eqn_idx: links.
+! - Both helpers are needed: controls/cbc-only-density.f90 and controls/cbc-only-velocity.f90 (one of the two
+!   calls removed) link on CCE 20; their check still counts the entries the removed helper fills (bad= 128).
+! Logs: data/reports/apps/ (cce20-*.txt).
+!
+! Basis (OpenMP 5.2): a conforming program, so the implementation must build and run it.
+! - §1.6 p.34 l.22-24: "An implementation of the OpenMP API is compliant if and only if it compiles and
+!   executes all other conforming programs, and supports the tool interfaces, according to the syntax and
+!   semantics laid out in Chapters 1 through 20."
+! - §7.8 p.204 l.16-17: "Declare target directives apply to procedures and/or variables to ensure that they
+!   can be executed or accessed on a device." (module variables, including a variable of derived type, and
+!   the three procedures; §7.8.1, declare target with a list and in a procedure.)
+! - §13.9 p.289 l.12-13: target update makes the device copies consistent before the region.
+! - §5.4.3 p.111 l.9-12 and §5.3 p.105 l.21-30: L, mf, drho, dvel, lambda, c, dp, i are private to each
+!   iteration; every element read is first written in that iteration (L by the helpers: 2..3 and 4..5, L(1)
+!   stays 0).
+! Race-free: out(:, r) is written by iteration r only. Legality was read against the spec; no compiler
+! under test, gfortran or gcc is a legality witness.
+!
+! MFC workaround (checked on MFC's own objects, ee99151, OpenMP): compile m_compute_cbc.fpp at -O0 with CCE 20
+! (CMakeLists.txt already sets per-file options for CCE, e.g. -Oipa0 for m_bubbles_EL;
+! set_source_files_properties(<build>/fypp/simulation/m_compute_cbc.fpp.f90 PROPERTIES COMPILE_OPTIONS -O0)):
+! the device link of every simulation object then succeeds (m_cbc alone at -O0 still crashes; both files at
+! -O1 crash), and MFC's own build (tools/jobs/run_mfc.sh MFC_VARIANT=o0cbc) builds and links. Its copy-mode test
+! subset: 155 of 159 pass; three Lagrange-bubble adap_dt tests (2122A4F6, 0D1FA5C5, 12ECE133) fail with "memory
+! access fault by GPU"; one (20AE0551, 2D bc=-4) was still running after 10 minutes and was stopped (not
+! examined).
+! Dropping fypp's --line-numbering is not enough: that build crashes in the same kernel (s_cbc ... L1640).
+module glob
+  implicit none
+  integer, parameter :: wp = kind(1.d0)
+  type idx_bounds_info
+    integer :: beg
+    integer :: end
+  end type idx_bounds_info
+  type eqn_idx_info
+    type(idx_bounds_info) :: cont, mom
+  end type eqn_idx_info
+  integer :: num_dims, num_fluids, sys_size
+  type(eqn_idx_info) :: eqn_idx
+  !$omp declare target (num_dims, num_fluids, sys_size, eqn_idx)
+end module glob
+
+module fill
+  use glob
+  implicit none
+  ! CCE's compile-time inlining off for the two helpers: they are inlined at the device link (LTO)
+  !DIR$ INLINENEVER s_fill_density, s_fill_velocity
+contains
+  subroutine s_fill_density(L, lambda2, c, mf, drho, dp)
+    !$omp declare target
+    real(wp), dimension(sys_size), intent(inout) :: L
+    real(wp), dimension(num_fluids), intent(in) :: mf, drho
+    real(wp), intent(in) :: lambda2, c, dp
+    integer :: i
+    do i = 2, eqn_idx%mom%beg
+      L(i) = lambda2*(c*c*drho(i - 1) - mf(i - 1)*dp)
+    end do
+  end subroutine s_fill_density
+  subroutine s_fill_velocity(L, lambda2, dvel)
+    !$omp declare target
+    real(wp), dimension(sys_size), intent(inout) :: L
+    real(wp), dimension(num_dims), intent(in) :: dvel
+    real(wp), intent(in) :: lambda2
+    integer :: i
+    do i = eqn_idx%mom%beg + 1, eqn_idx%mom%end
+      L(i) = lambda2*dvel(i - eqn_idx%cont%end)
+    end do
+  end subroutine s_fill_velocity
+  subroutine s_outflow(lambda, L, c, mf, drho, dp, dvel)
+    !$omp declare target
+    real(wp), dimension(3), intent(in) :: lambda
+    real(wp), dimension(sys_size), intent(inout) :: L
+    real(wp), dimension(num_fluids), intent(in) :: mf, drho
+    real(wp), dimension(num_dims), intent(in) :: dvel
+    real(wp), intent(in) :: c, dp
+    call s_fill_density(L, lambda(2), c, mf, drho, dp)
+    call s_fill_velocity(L, lambda(2), dvel)
+  end subroutine s_outflow
+end module fill
+
+program cce20_infer_address_spaces
+  use fill
+  implicit none
+  integer, parameter :: nr = 64
+  real(wp), allocatable :: out(:, :)
+  real(wp) :: L(5), mf(2), drho(2), dvel(3)
+  real(wp) :: lambda(3), c, dp, expect
+  integer :: r, i, bad
+  num_dims = 3; num_fluids = 2
+  eqn_idx%cont%beg = 1; eqn_idx%cont%end = num_fluids
+  eqn_idx%mom%beg = eqn_idx%cont%end + 1; eqn_idx%mom%end = eqn_idx%cont%end + num_dims
+  sys_size = eqn_idx%mom%end
+  !$omp target update to(num_dims, num_fluids, sys_size, eqn_idx)
+  allocate(out(sys_size, nr))
+  out = 0
+  !$omp target teams distribute parallel do private(L, mf, drho, dvel, lambda, c, dp, i) map(tofrom: out)
+  do r = 1, nr
+    do i = 1, num_fluids
+      mf(i) = 0.5_wp*i
+      drho(i) = 0.25_wp*i + r
+    end do
+    do i = 1, num_dims
+      dvel(i) = 1._wp*i + r
+    end do
+    lambda = [1._wp, 2._wp, 3._wp]
+    c = 2._wp; dp = 0.5_wp
+    L = 0
+    call s_outflow(lambda, L, c, mf, drho, dp, dvel)
+    out(:, r) = L
+  end do
+  !$omp end target teams distribute parallel do
+  bad = 0
+  do r = 1, nr
+    do i = 1, sys_size
+      expect = 0
+      if (i >= 2 .and. i <= 3) expect = 2*(4*(0.25_wp*(i - 1) + r) - 0.5_wp*(i - 1)*0.5_wp)
+      if (i >= 4) expect = 2*(1._wp*(i - 2) + r)
+      if (out(i, r) /= expect) bad = bad + 1
+    end do
+  end do
+  print '(a,i0,a,5f8.2)', 'bad= ', bad, ' out(:,1)=', out(:, 1)
+end program cce20_infer_address_spaces
+! site:
+! title: ftn 20: the device link crashes in "Infer address spaces" (an MFC kernel, reduced)
+! control: ../vendor/checks/src/cce/control/cce20-device-link-infer-address-spaces-crash-control.f90 the !DIR$ INLINENEVER line
+! + removed (CCE inlines the two helpers)
+! end site