Repository navigation
CI: build the support library with the Conda compiler (backport of #636) - #744
Merged
Merged
Conversation
A bare `icpx` resolves to the site oneAPI installation when one is on PATH, which links the support library against that installation's libsycl instead of the Conda toolkit the RPATH points at. On Aurora this fails with `undefined reference to ur*Exp@LIBUR_LOADER_0.12` in the `build:support` job. The test job also drops the site oneAPI entries from LD_LIBRARY_PATH so SYCL is pure Conda, as on main. Only the two CI hunks of #636 are backported; the oneMKL 2026.1.0 wrapper bump stays on main. (cherry picked from commit 5093529)
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## release-2.9 #744 +/- ##
===============================================
- Coverage 81.54% 81.48% -0.06%
===============================================
Files 50 50
Lines 3608 3608
===============================================
- Hits 2942 2940 -2
- Misses 666 668 +2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
michel2323
referenced
this pull request
Oct 27, 2026
The KernelAbstractions back-end returned the hardware global id for `@index(Global, Linear)`. That only equals the linear index into `ndrange` when the work-group size divides every dimension of it; otherwise KernelAbstractions pads the range and kernels skip elements and write out of bounds. GPUArrays' `getindex`, `permutedims` and `rmul!` kernels all rely on this index, so e.g. `x[:, 1:2]` on a 513x3 matrix returned zeros, `x[:, 2, :, :]` on a (64, 4, 500, B) array was wrong for every B >= 2, and `rmul!` on a (64, 1000, 16) ComplexF32 array page-faulted. Map the id through the iteration space instead, as the CPU back-end and CUDA.jl do, and add regression tests for padded N-d ranges with automatic and explicit work-group sizes plus the reported `getindex`, `permutedims` and `rmul!` cases. Backport to the 2.9 series (KernelAbstractions 0.9 / GPUArrays 11); main gets this through the KernelInterface back-end (#653). Analysis and patch by Wilkie Olin-Ammentorp (@wilkieolin). Fixes #509 Co-authored-by: Wilkie Olin-Ammentorp <10157823+wilkieolin@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backports the two CI-only hunks of #636 to
release-2.9so the ALCF Aurora check is meaningful on the 2.9 branch:deps/build_local.jl: use the Condaicpx(andLIBRARY_PATH) explicitly. With a bareicpx, a site oneAPI module onPATHis picked up and the support library links against itslibsycl, which on Aurora fails withundefined reference to ur*Exp@LIBUR_LOADER_0.12(see thebuild:supportfailure on Fix@index(Global, Linear)for padded ndranges (2.9 backport) #738)..gitlab-ci.yml: strip/opt/aurora/*/oneapi/fromLD_LIBRARY_PATHintest:lts, so the Conda SYCL runtime is not mixed with the site UR adapter.The oneMKL 2026.1.0 wrapper bump from #636 is not included; the release branch keeps the 2025.3.1 wrappers and
oneAPI_Support_jll0.10. No package code changes.