llama.cpp b11509修复CUDA构建中CCCL版本判断在跨大版本时误判的问题
该版本修正了argsort的CCCL版本守卫：原先分别比较主版本与次版本，在CCCL 4.x上会误判为不满足条件，导致strided iterator路径被静默禁用、回退到init_offsets，形成无编译报错的性能损失。
AI解读：改动针对ggml CUDA后端argsort的CCCL版本判断。原守卫写法为CCCL_MAJOR_VERSION >= 3 && CCCL_MINOR_VERSION >= 1，次版本在跨大版本时会归零，因此在CCCL 4.x上被算成 4>=3 && 0>=1，结果为false。
后果是STRIDED_ITERATOR_AVAILABLE不再被定义，argsort静默回退到init_offsets路径，构建仍成功、没有任何警告，属于不报错的性能回退。
修法是改用CCCL自身版本头采用的单一打包整数形式：CCCL_VERSION = 主版本*1000000 + 次版本*1000 + 补丁，于是 3.4.3 为 3004003，“>=3.1”直接写成“>=3001000”，避免分量运算出错。
作者按 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、5.0.0 与手写参考实现比对，未发现分歧；旧守卫在 4.0.0 和 5.0.0 上判断不一致。
验证环境为RTX 4070（sm_89）、CUDA 13.4、CCCL 3.4.3：Release构建退出码 0，test-backend-ops的ARGSORT用例 98/98 通过。作者同时说明，回归测试通过本身不能证明守卫被采用，因为回退路径也会通过；对真实编译单元预处理后确认走的是strided-iterator分支。
llama.cpp发布b11509，其中一项改动修复CUDA构建里CCCL版本守卫在跨大版本时误判的问题（PR #29453）。
误判的成因与影响
改动说明称，原守卫分别比较主版本与次版本：CCCL_MAJOR_VERSION >= 3 && CCCL_MINOR_VERSION >= 1。由于每次开启新的大版本系列时次版本会重置为 0，这条表达式在CCCL 4.x上变成 4 >= 3 && 0 >= 1，即false。
据此，STRIDED_ITERATOR_AVAILABLE不再被定义，argsort静默回退到init_offsets路径。改动说明强调没有任何警告、构建仍然成功，因此这是不报错的性能损失，而不是编译错误。
修复方式与验证
修复改用CCCL自身版本头使用的单一打包整数：CCCL_VERSION = MAJOR * 1000000 + MINOR * 1000 + PATCH。于是 3.4.3 对应 3004003，而“>= 3.1”变为直接比较“>= 3001000”，不再需要分量算术。
作者把新写法与手写的“version >= 3.1”参考实现在 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、5.0.0 上比对，未发现分歧；旧守卫在 4.0.0 和 5.0.0 上判断不一致。
在RTX 4070（sm_89）、CUDA 13.4、CCCL 3.4.3上，cmake --build build --config Release退出码为 0，test-backend-ops test -o ARGSORT -b CUDA0为 98/98 通过。改动说明同时指出，回归测试通过并不能证明守卫仍被采用，因为回退路径同样会通过；对真实编译单元做预处理后确认，编译进去的是strided-iterator分支（存在counting_iterator，不存在init_offsets）。