[python] Crash when cudaq.adjoint is followed by cudaq.control on the same kernel with a constant argument

[iarjunganesh]

Required prerequisites

• Consult the security policy. If reporting a security vulnerability, do not report the bug using this form. Use the process described in the policy to report the issue.
• Make sure you've read the documentation. Your issue may be addressed there.
• Search the issue tracker to verify that this hasn't already been reported. +1 or comment there if it has.
• If possible, make a PR with a failing test to give us a starting point to work on!

Describe the bug

Hi, and thank you for all the work on CUDA-Q! I came across a crash that I don't think has been reported yet, though please let me know if I missed an existing issue.

In a Python kernel, calling cudaq.adjoint(k, ...) followed by cudaq.control(k, ...) on the same kernel aborts the process with a failed assertion when the kernel argument is a compile-time constant, either a literal or a local variable:

/usr/include/c++/12/bits/stl_vector.h:1125: ... std::vector<mlir::BlockArgument>::operator[](size_type) ...: Assertion '__n < this->size()' failed.
Aborted (exit code 134)

From what I could narrow down:

Order in the caller	Argument passed	Result
adjoint, then control	literal (1.5)	crash
adjoint, then control	local variable (theta = 1.5)	crash
adjoint, then control	caller's kernel argument (theta: float)	works
control, then adjoint	literal (1.5)	works
each on its own	literal	works

The equivalent C++ program, compiled with nvq++, runs fine, so this seems specific to the Python frontend.

Steps to reproduce the bug

import cudaq


@cudaq.kernel
def my_func(q: cudaq.qubit, theta: float):
    ry(theta, q)
    rz(theta, q)


@cudaq.kernel
def kernel():
    ancilla = cudaq.qubit()
    q = cudaq.qubit()
    h(ancilla)
    cudaq.adjoint(my_func, q, 1.5)
    cudaq.control(my_func, ancilla, q, 1.5)


cudaq.sample(kernel).dump()  # aborts with the assertion above

Swapping the last two lines of kernel, or making theta an argument of kernel and passing it through, makes it run correctly.

For reference, test_control_then_adjoint in python/tests/kernel/test_kernel_features.py covers the control-then-adjoint order with a runtime argument. I couldn't find a test for the reverse order with a constant argument.

Expected behavior

The kernel compiles and samples normally, as it does in C++ and with the reversed call order. For example: { 00:~250 01:~250 10:~500 }.

Is this a regression? If it is, put the last known working version (or commit) here.

Not sure. A related adjoint/control combination was fixed in #1871 (#1979, #1993), but I haven't found a version where this exact case worked.

Environment

• CUDA-Q version: 0.16.0 (pip wheel), and the nightly image nvcr.io/nvidia/nightly/cuda-quantum:cu12-latest at commit 934e7065
• Python version: 3.12
• C++ compiler: N/A (the C++ equivalent built with nvq++ from the same nightly image works)
• Operating system: Ubuntu on WSL2 (x86_64) for the wheel; the nightly container for the nightly build

Suggestions

I haven't dug into the root cause yet. Since it only fails for constant arguments and only when adjoint comes first, I wonder whether the argument synthesis or constant propagation for the .adj variant is changing the callee's signature before the .ctrl variant is generated. That's only a guess, though. I'd be happy to contribute a failing regression test, or to help investigate further, if that would be useful.

[iarjunganesh]

A small update in case it's helpful: I traced this to constant propagation in ApplyOpAnalysis::processApplyOp. When the first apply is specialized, the shared cc.instantiate_callable gets redirected for every quake.apply that uses it, not just the current one. That leaves the second apply's callee and closure pointing at different clones. It also looks like a regression since 0.16.0 (cudaq==0.15.0 runs the reproducer fine). I've opened #5493 with a proposed one-line fix and regression tests (lit + Python). I'm very happy to rework it if you'd prefer a different approach. Thank you!

[rupasri118]

Hi! I’d like to work on this issue as my first contribution to CUDA-Q.
I went through the reproduction case and understand that the crash occurs when cudaq.adjoint is followed by cudaq.control with a constant argument.
I’d like to investigate the issue and work on the required fix and regression tests. Would it be okay to assign this issue to me?

[iarjunganesh]

Hi @rupasri118, thank you for taking an interest in this issue, and welcome! I've already opened #5493 with a proposed fix and regression tests, and it has now received maintainer approval. I wanted to share that context to help avoid duplicate work. If you spot any additional cases or have feedback on the tests, I'd be glad to hear it. Thank you!

[rupasri118]

Thanks for the clarification @iarjunganesh ! Since #5493 already contains the proposed fix, would there be any additional work or tests I could take up for this issue? I’d be happy to work on a separate improvement if needed.

[iarjunganesh]

Hi @rupasri118, thank you for offering to help!
#5493 already includes regression tests for both call orders with different constants. One possible follow-up to explore would be three or more adjoint/control calls sharing the same callable, checking the resulting state against equivalent plain gates. I haven’t investigated that case yet, so I’d welcome the maintainers’ thoughts on whether it would add useful coverage.
If you’d prefer a separate improvement, perhaps the maintainers could suggest an issue suitable for a first contribution. Thanks again for your interest!