refactor(gpu): finish the cuda::std::complex migration (Cpr/Mod/cuOuter) and delete cucomplex_arithmetic

[yingjerkao]

Summary

Completes #1004's migration of the GPU element-wise ops to cuda::std::complex and deletes the hand-rolled utils/cucomplex_arithmetic.{hpp,cu}.

#1004 introduced the cuda::std::complex infrastructure (Type_list_gpu, gpu_ptr()/gpu_ptr_as<T>(), type_promote_gpu_t) and migrated Add/Sub/Mul/Div (and cuKron) to a typed dispatch path — but left Cpr, Mod, and cuOuter on the legacy cuComplex path, which still depended on the mixed-type operator==/operator* overloads in cucomplex_arithmetic. Those overloads are also the ones flagged as wrong-by-promotion in the #995 / #994 discussion (cuFloatComplex * double -> cuFloatComplex, dropping precision after #858 made ComplexFloat*Double -> ComplexDouble); they can't be fixed in isolation because the generated GPU dispatch tables rely on the truncating behavior. Routing everything through the cuda::std::complex typed path (which promotes correctly and casts to the ABI only at cuBLAS/cuSOLVER boundaries) is the real fix Ian suggested on #995.

Supersedes the narrow Kron-only patch in #995.

What changed (staged, one op per commit)

1. Cpr → new cuCpr_dispatch (mirrors cuMul_dispatch): out(bool) = (TO(lhs) == TO(rhs)), TO = type_promote_gpu(TL,TR). Casting to TO first is required because cuda::std::complex has no mixed-type operators (complex<float> == double is ill-formed) and reproduces the old make_cuDoubleComplex(v,0) widening. 13 Cpr.cpp call sites rewired off cuAri_ii.
2. Mod → cuMod_dispatch: per-category (% for integral, fmod/fmodf for floating, complex rejected at host — matches the CPU ModOp<T>). 25 Mod.cpp call sites rewired.
3. cuOuter → cuda::std::complex types + TO(a)*TO(b) cast kernel; the 4 hand-added cuGer (cuBLAS ger) fast paths preserved; boostraps/cy_type.py cuDTYPES_FULL updated for consistency.
4. Cleanup → delete cucomplex_arithmetic.{hpp,cu} + the dead legacy cuCpr_internal kernels + the 120 dead type==4 branches in the cuArithmetic_internal forwarders (Cpr has no in-place variant, so type==4 is never dispatched). Net −3,630 lines.

Validation

Built + tested locally on real GPU hardware (CUDA 13.0, RTX 4070 Ti, sm_89) — CI has no CUDA runner, so this path is not exercised by CI:

• libcytnx.a compiles + device-links + host-links — confirms the deletions/forwarder edits leave no dangling symbols (what a front-end-only check can't catch).
• *cpr* GPU tests: 80/80 passed (cuCpr_dispatch).
• *mod* GPU tests: 49/49 passed (cuMod_dispatch).
• In-place iadd/isub/imul/idiv: 8/8 passed — regression check that stripping type==4 from the shared cuArithmetic_internal forwarders didn't break the live in-place path (which still uses cuAri_ii).

cuOuter has no GPU runtime test in-tree, but it compiles + links.

Notes / follow-ups (not in this PR)

• The legacy cuAri_ii → cuArithmetic_internal → cuAdd/Mul/Sub/Div/Mod_internal layer stays: it's still used by the in-place ops (iAdd/iSub/iMul/iDiv), via cuComplex.h builtins (cuCadd/cuCmul), not the deleted operators. Migrating those four would let the whole legacy layer be deleted.
• Test-build config gap (from Use cuda::std::complex for typed GPU complex dispatch #1004): gpu_test_main's host-compiled test .cpp files include Type.hpp → <cuda/std/complex> but the tests/gpu CMake target lacks the CCCL include dir (-I.../include/cccl) that the cytnx library target has, so the GPU test binary doesn't build out-of-the-box under CUDA 13. Worth fixing in tests/gpu/CMakeLists.txt.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request refactors GPU complex arithmetic by removing the custom cucomplex_arithmetic utilities and transitioning to cuda::std::complex (via cytnx_cuda_complex128/64). It introduces cuCpr_dispatch.cu and cuMod_dispatch.cu to handle GPU dispatching for comparison and modulo operations. The reviewer identified critical issues in both dispatch files where the host code attempts to write directly to device-allocated pointers (m_accu_shape, m_old_accu_shapeL, and m_old_accu_shapeR), which would result in segmentation faults. It is recommended to compute these values on the host first and then copy them to the device using cudaMemcpy.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[yingjerkao]

Re: @gemini-code-assist review — both "critical" findings are false positives

Gemini flagged the non-contiguous branches in cuCpr_dispatch.cu and cuMod_dispatch.cu as host writes to device-only pointers (m_accu_shape / m_old_accu_shapeL / m_old_accu_shapeR) that would segfault. They won't:

• cuCalloc_gpu / cuMalloc_gpu allocate managed (unified) memory via cudaMallocManaged (src/backend/utils_internal_gpu/cuAlloc_gpu.cu:9-19), not device-only memory — so writing those arrays from the host is valid; the pages migrate to the device on the kernel launch.
• This is the identical pattern used by the already-merged cuAdd_dispatch / cuMul_dispatch from Use cuda::std::complex for typed GPU complex dispatch #1004, which I mirrored deliberately.
• Verified on real hardware (CUDA 13.0, RTX 4070 Ti): *cpr* (80/80) and *mod* (49/49) GPU tests pass, including the non-contiguous multi-dim shapes ({16,16,16,16}, {64,64,64}, …) that exercise exactly this shape.size() > 0 branch — a host write to device-only memory would have crashed there.

No changes needed for either finding. (Replied inline on both threads as well.)

[gemini-code-assist]

Thank you for the detailed explanation and for verifying the behavior on hardware. Your points regarding the use of managed memory (cudaMallocManaged) and the consistency with existing patterns in cuAdd_dispatch / cuMul_dispatch are well-taken. Since the memory is managed, the host-to-device migration is handled correctly by the CUDA runtime upon kernel launch, and your testing confirms that the non-contiguous shape branches function as expected without memory access violations. I have noted your clarification.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 55.62%. Comparing base (3268385) to head (fffbde5).
⚠️ Report is 1 commits behind head on master.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1019   +/-   ##
=======================================
  Coverage   55.62%   55.62%           
=======================================
  Files         230      230           
  Lines       33099    33099           
  Branches       77       77           
=======================================
  Hits        18412    18412           
  Misses      14662    14662           
  Partials       25       25           

Flag	Coverage Δ
cpp	55.55% <ø> (ø)
python	61.84% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
C++ backend	53.30% <ø> (ø)
Python bindings	70.35% <ø> (ø)
Python package	61.84% <ø> (ø)

Files with missing lines	Coverage Δ
src/linalg/Cpr.cpp	14.18% <ø> (ø)
src/linalg/Mod.cpp	72.70% <ø> (ø)

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3268385...fffbde5. Read the comment docs.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[IvanaGyro]

The problems on cpr also on mod. I reviewed on my phone. The screen is so small that I may misread something.

Do the problems I addressed comes from the original implementation?

[IvanaGyro]

I haven't known that cpr means compare until now. cmp, cp, comp are more common in software. We can consider to rename it. Or maybe, "equal" is a more accurate for this function.

[IvanaGyro]

512 should be a kConstant with a proper name.

[IvanaGyro]

Do we really need both lconst, and rconst?
Should we follow naming rule while refactoring the whole file?

[IvanaGyro]

If invmapper is needed here, the input type may be tensor instead of storage

[IvanaGyro]

If len is always 1 here, this is a trivial action, and constconst_kernel is not needed.

[ianmccul]

well, it certainly doesn't need 512 threads... but since _out is also on GPU it is probably better to launch GPU kernel for this, versus copying the parameters to host memory then back to GPU. But I don't understand why this needs to be a special case.

[ianmccul]

Reiterating the comment here since it is a reply to a 'resolved' comment:

It is a false positive in some sense - it will actually work without segfaulting, but it is terrible style and very slow. All of these arrays are very short, it would be far better to assemble the data into a small fixed size structure and pass it directly into the kernel as a parameter, similar style as the TraceLayout structure in src/backend/linalg_internal_gpu/cuTrace_internal.cu .

Writing these tiny arrays through unified memory is particularly bad: the first write will need to copy the entire memory page from GPU to CPU (probably every array ends up on a different page), then copy it back once the GPU kernel needs the memory.

[ianmccul]

On second thoughts, it is probably not worth fixing the previous comment but just merge this as-is. I'll prepare a PR for #1003 anyway. This PR is still needed for the other fixes to remove the cuFloat types.

[IvanaGyro]

I see the kernel implementatipn in this PR is just a copy from the old code. We can fix them in future.