CUDA: fix CCCL version guard breaking on major version rollover

[hey-gm]

Summary

ggml/src/ggml-cuda/argsort.cu gates STRIDED_ITERATOR_AVAILABLE on a
CCCL version check that compares the major and minor components
independently:

#if (CCCL_MAJOR_VERSION >= 3 && CCCL_MINOR_VERSION >= 1)

The minor component resets to 0 whenever a new major series is cut. On
CCCL 4.x the condition therefore evaluates as 4 >= 3 && 0 >= 1, which
is false. The macro goes undefined and argsort silently falls back to
the init_offsets path. The build still succeeds and nothing warns, so
this lands as a quiet performance regression rather than a build break.

Root cause

Comparing version components separately is only correct within the
current major series. It implicitly assumes the minor component keeps
increasing, which stops being true at every major-version boundary.

CCCL already publishes the version as a single packed integer in
MMMmmmpp form, which is what its own version header defines:

#define CCCL_VERSION 3004003
#define CCCL_MAJOR_VERSION (CCCL_VERSION / 1000000)
#define CCCL_MINOR_VERSION (((CCCL_VERSION / 1000) % 1000))
#define CCCL_PATCH_VERSION (CCCL_VERSION % 1000)

so 3.4.3 is 3004003, and "at least 3.1" is a plain >= 3001000. That
leaves a single comparison with no component arithmetic to get wrong.

The fix

-#    if (CCCL_MAJOR_VERSION >= 3 && CCCL_MINOR_VERSION >= 1)
+    // CCCL_VERSION is packed MMMmmmpp: 3.4.3 -> 3004003
+#    if (CCCL_VERSION >= 3001000)

Testing

RTX 4070 (sm_89), CUDA 13.4.92, CCCL 3.4.3, Ubuntu 26.04.

• cmake --build build --config Release - exit 0
• test-backend-ops test -o ARGSORT -b CUDA0 - 98/98 passed, CUDA0 OK

The new guard was checked against a hand-written "version >= 3.1"
reference across 2.9.9, 3.0.0, 3.1.0, 3.1.99, 3.2.0, 3.4.3, 3.9.9,
3.99.99, 4.0.0, 4.2.7 and 5.0.0, with no divergences. The previous
guard disagreed at 4.0.0 and 5.0.0.

Worth noting that a green test-backend-ops run does not by itself show
the guard is still taken, because the fallback path passes those tests
as well. Preprocessing the real translation unit confirms the
strided-iterator branch is the one being compiled in: counting_iterator
is present and init_offsets is not.

Note

ggml/src/ggml-cuda/top-k.cu carries the same defect with a >= 3.2
threshold. It is left untouched here to keep this change reviewable on
its own; a follow-up PR for it would be welcome.

[ggml-gh-bot]

Hi @hey-gm, thanks for your contribution!

Per our contribution guidelines, the automated PR checker found the following issue(s) that need your attention:

• PR Template not respected: Please respect the template when creating a new pull request. Make sure to fill out all required sections.

---

Please note that maintainers reserve the right to make final decisions on PRs. If you believe there is a mistake, please comment below.

[Copilot]

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Copilot review overview

Review effort: Lite
Findings: 1

Open (1)

• The threshold 3001000 is a magic number. Consider defining a named macro (e.g., `#define… · New

What changed in this PR

Updates the CUDA argsort CCCL version guard to avoid a silent performance regression when CCCL rolls over to a new major version (where the minor resets to 0).

Changes:

• Replace separate CCCL_MAJOR_VERSION/CCCL_MINOR_VERSION comparisons with a single packed CCCL_VERSION comparison for the STRIDED_ITERATOR_AVAILABLE gate.
• Add a brief comment documenting CCCL’s packed version format.

File	Description
ggml/​src/​ggml-cuda/​argsort.cu	Fixes CCCL version gating logic so the strided-iterator path remains enabled across major version rollovers.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ORippler]

Thanks!