Bug(Enzyme): jl_call/_compute_sparams in aug_forward inside ForwardDiff prepare_jacobian (two-arg) on Julia 1.12

[ChrisRackauckas-Claude]

Summary

When Enzyme reverse-mode tries to differentiate through a function that internally calls DI.prepare_jacobian(f!, y, AutoForwardDiff(), x, Constant(p)) (the two-arg ForwardDiff path), it fails with

Enzyme: jl_call calling convention not implemented in aug_forward
for   %jl_f__compute_sparams_ret = call ...
       @julia.call(@jl_f__compute_sparams,
                   null,
                   @"ejl_inserted$_DifferentiationInterfaceForwardDiffExt_dual_type_*",
                   @"ejl_inserted$jl_global_*",
                   ...)

inside prepare_jacobian_nokwarg at ext/DifferentiationInterfaceForwardDiffExt/twoarg.jl:381 (line 388: contexts_dual = translate_toprep(dual_type(config), contexts)).

The triggering site is the JacobianConfig overload of dual_type in utils.jl:

# ext/DifferentiationInterfaceForwardDiffExt/utils.jl, lines 29-32
dual_type(config::DerivativeConfig) = eltype(config.duals)
dual_type(config::GradientConfig) = eltype(config.duals)
dual_type(config::JacobianConfig{T, V, N}) where {T, V, N} = Dual{T, V, N}   # <-- this one
dual_type(config::HessianConfig) = dual_type(config.gradient_config)

The JacobianConfig{T, V, N} form pattern-matches the parametric type. On Julia 1.12, the resulting LLVM IR emits a runtime jl_f__compute_sparams call (via Julia's generic jl_call calling convention) to materialize the type parameters. Enzyme's aug_forward pass has no handler for that specific jl_call, and it errors out.

The other three overloads use eltype(config.duals) and do not trigger this codegen.

MWE

This reproduces fully isolated (no MTK, no RGF needed — just NonlinearSolve calling DI):

using NonlinearSolve, Enzyme
using SciMLBase: NonlinearProblem, remake

function f_plain!(du, u, p)
    du[1] = u[1] - p[1] + p[2]
    return nothing
end

prob = NonlinearProblem(f_plain!, [0.0], [2.0, 1.0])

loss(p) = sum(solve(remake(prob; p = p), NewtonRaphson()).u)

Enzyme.gradient(
    Enzyme.set_runtime_activity(Enzyme.Reverse),
    Enzyme.Const(loss),
    [2.0, 1.0],
)
# EnzymeRuntimeException: Enzyme: jl_call calling convention not implemented in aug_forward
# at prepare_jacobian_nokwarg(...)
#    @ DifferentiationInterfaceForwardDiffExt .../ext/.../twoarg.jl:381

Versions:

• Julia 1.12.6
• DifferentiationInterface 0.7.18
• ForwardDiff 1.3.3
• Enzyme 0.13.148
• NonlinearSolve 4.19.1

Setting NewtonRaphson() explicitly is just to avoid the polyalgorithm Union; Const(loss) + set_runtime_activity(Reverse) are the documented Enzyme annotations for a closure capturing a mutable NonlinearProblem.

Proposed fix (one line)

Use the same nested-eltype shape the other dispatches already use:

# ext/DifferentiationInterfaceForwardDiffExt/utils.jl
dual_type(config::JacobianConfig) = eltype(eltype(config.duals))

For a JacobianConfig{T, V, N}, eltype(config.duals) is Vector{Dual{T, V, N}} (a tuple of two such vectors) and eltype of that is Dual{T, V, N} — same result, different (Enzyme-tractable) codegen.

Verification

With a runtime monkey-patch of exactly the above one line:

import ForwardDiff, DifferentiationInterface as DI
DIExtMod = Base.get_extension(DI, :DifferentiationInterfaceForwardDiffExt)
Core.eval(DIExtMod,
    :(dual_type(config::ForwardDiff.JacobianConfig) = eltype(eltype(config.duals))))

the _compute_sparams / jl_call error in prepare_jacobian_nokwarg disappears. The original MWE then advances four steps further into the stack before hitting an unrelated downstream Enzyme/LinearSolve issue (NonConstantKeywordArgException in LinearSolve.init) — confirming this issue is exactly localized to the dual_type(::JacobianConfig) codegen pattern on Julia 1.12.

Context

This is the upstream layer of SciML/SciMLSensitivity.jl#1359, which tracks Enzyme reverse-mode through solve(remake(prob; p), NewtonRaphson()) for MTK-built problems. After four layers of user-side and library-side fixes (closing the closure with Const, enabling set_runtime_activity, passing an explicit alg, fixing the MTK supports_initialization mutation), this DI ForwardDiff dual_type codegen pattern is the next blocker.

Happy to open a PR if the proposed one-liner looks right.

[ChrisRackauckas]

@wsmoses looks like this is what it got tracked down, not sure why Enzyme would be sensitive to that but 🤷 it doesn't seem incorrect to do. @gdalle does the one dispatch seem reasonable?

[wsmoses]

have the bot also figure out an mwe of tihs [e.g. removing as much of DI as possible, obviously calling the internals] to Enzyme and I'll also look there as well.

Fundamentally what's happening is that there's a very weird type instability coming through from DI -- one we've never seen before. This should be fixed in both places (though technically only one is required for you)

[ChrisRackauckas-Claude]

@wsmoses here is the Enzyme-only MWE (no DI, no ForwardDiff, no struct):

using Enzyme

dual_type(c::NTuple{N, Float64}) where {N} = Val{N}

function loss(x::Vector{Float64})
    t = ntuple(_ -> 0.0, length(x))   # NTuple{_A, Float64} where _A — non-inferable N
    return sum(x) + (dual_type(t) === Val{2} ? 0.0 : 1.0)
end

Enzyme.gradient(
    Enzyme.set_runtime_activity(Enzyme.Reverse),
    Enzyme.Const(loss),
    [1.0, 2.0]
)

Versions: Julia 1.12.6, Enzyme 0.13.148.

Output:

ERROR: LoadError: EnzymeRuntimeException: Enzyme execution failed within

loss(::Vector{Float64})

Enzyme: jl_call calling convention not implemented in aug_forward for
  %jl_f__compute_sparams_ret = call nonnull ... @julia.call(
      ptr nonnull @jl_f__compute_sparams,
      ptr addrspace(10) null,
      ptr addrspace(10) @"ejl_inserted$_Main_dual_type_...",
      ptr addrspace(10) @"ejl_inserted$jl_global_...",
      ptr addrspace(10) %value_phi90)

Trigger pieces I needed / ruled out:

• Required: a where-bound method whose argument's type parameter is a free typevar at the call site. Here ntuple(_->0.0, length(x)) is inferred as NTuple{_A, Float64} where _A, so the where-bound dual_type(::NTuple{N, Float64}) where N forces Julia to emit Core._compute_sparams to extract N. Same shape as DI's dual_type(::JacobianConfig{T,V,N}) where {T,V,N} = Dual{T,V,N}.
• Required: Julia 1.12. On Julia 1.10 this MWE runs cleanly (SUCCESS: ([1.0, 1.0],)). On Julia 1.11 it fails with a different Enzyme message (No augmented forward pass found for jl_get_builtin_fptr ... _compute_sparams) — same underlying gap, different emit path (1.12 emits via julia.call wrapper hitting jlcall_augfwd; 1.11 emits a direct jl_get_builtin_fptr call).
• Not required: no custom struct, no Dual type, no mutable input, no Val wrapper, no nested dual_type(::JacobianConfig) shape. The wrapping prepare/@noinline boundary isn't needed either. Just one function with a non-concrete-N call into a where N method.
• Not required: ForwardDiff, DifferentiationInterface.

In your jlcall_augfwd dispatch table (Enzyme/src/rules/llvmrules.jl ~220–283) _compute_sparams is not handled, so it falls through to the not implemented in aug_forward emit. There is an inactive_noinl rule for it in internal_rules/inactive.jl:109, but the llvmrules-level dispatch doesn't pick that up. Treating _compute_sparams as inactive in jlcall_augfwd (and the 1.11 jl_get_builtin_fptr path) seems right — it's a pure type-level operation with no derivative content.

[wsmoses]

enzyme side fixed in: EnzymeAD/Enzyme.jl#3119

Note the code is unquestionably type unstable in DI, see

julia> a = err
1-element ExceptionStack:
codeEnzymeRuntimeException: Enzyme execution failed within

loss(::Vector{Float64})
     @ Main REPL[3]:1

Hint: catch this exception as `err` and call `code_typed(err)` to inspect the surrounding code.

Enzyme: jl_call calling convention not implemented in aug_forward for   %jl_f__compute_sparams_ret = call nonnull "enzyme_type"="{[-1]:Pointer}" ptr addrspace(10) (ptr, ptr addrspace(10), ...) @julia.call(ptr nonnull @jl_f__compute_sparams, ptr addrspace(10) null, ptr addrspace(10) @"ejl_inserted$_Main_dual_type_5975$false$4537180944", ptr addrspace(10) @"ejl_inserted$jl_global_5976$false$4670552056", ptr addrspace(10) %value_phi90) #20, !dbg !60

Stacktrace:
  [1] ntuple
    @ ./ntuple.jl:19 [inlined]
  [2] loss
    @ ./REPL[3]:2 [inlined]
  [3] diffejulia_loss_5972wrap
    @ ./REPL[3]:0
  [4] macro expansion
    @ ~/git/Enzyme.jl2/src/compiler.jl:6855 [inlined]
  [5] enzyme_call
    @ ~/git/Enzyme.jl2/src/compiler.jl:6325 [inlined]
  [6] CombinedAdjointThunk
    @ ~/git/Enzyme.jl2/src/compiler.jl:6209 [inlined]
  [7] autodiff
    @ ~/git/Enzyme.jl2/src/Enzyme.jl:536 [inlined]
  [8] macro expansion
    @ ~/git/Enzyme.jl2/src/sugar.jl:337 [inlined]
  [9] gradient(::ReverseMode{false, true, false, FFIABI, false, false}, ::Const{typeof(loss)}, ::Vector{Float64})
    @ Enzyme ~/git/Enzyme.jl2/src/sugar.jl:274
 [10] top-level scope
    @ REPL[4]:1


julia> code_typed(err.stack[1].exception)
1-element Vector{Any}:
 CodeInfo(
1 ── %1   =   builtin Base.getfield(x, :size)::Tuple{Int64}
│    %2   = $(Expr(:boundscheck, true))::Bool
│    %3   =   builtin Base.getfield(%1, 1, %2)::Int64
│    %4   =   builtin (%3 === 0)::Bool
└───        goto #3 if not %4
2 ──        goto #34
3 ── %7   =   builtin (%3 === 1)::Bool
└───        goto #5 if not %7
4 ──        goto #33
5 ── %10  =   builtin (%3 === 2)::Bool
└───        goto #7 if not %10
6 ──        goto #32
7 ── %13  =   builtin (%3 === 3)::Bool
└───        goto #9 if not %13
8 ──        goto #31
9 ── %16  =   builtin (%3 === 4)::Bool
└───        goto #11 if not %16
10 ─        goto #30
11 ─ %19  =   builtin (%3 === 5)::Bool
└───        goto #13 if not %19
12 ─        goto #29
13 ─ %22  =   builtin (%3 === 6)::Bool
└───        goto #15 if not %22
14 ─        goto #28
15 ─ %25  =   builtin (%3 === 7)::Bool
└───        goto #17 if not %25
16 ─        goto #27
17 ─ %28  =   builtin (%3 === 8)::Bool
└───        goto #19 if not %28
18 ─        goto #26
19 ─ %31  =   builtin (%3 === 9)::Bool
└───        goto #21 if not %31
20 ─        goto #25
21 ─ %34  =   builtin (%3 === 10)::Bool
└───        goto #23 if not %34
22 ─        goto #24
23 ─ %37  =    invoke Base._ntuple(var"#loss##0#loss##1"()::var"#loss##0#loss##1", %3::Int64)::Tuple{Vararg{Float64}}
24 ┄ %38  = φ (#22 => (0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0), #23 => %37)::Tuple{Vararg{Float64}}
25 ┄ %39  = φ (#20 => (0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0), #24 => %38)::Tuple{Vararg{Float64}}
26 ┄ %40  = φ (#18 => (0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0), #25 => %39)::Tuple{Vararg{Float64}}
27 ┄ %41  = φ (#16 => (0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0), #26 => %40)::Tuple{Vararg{Float64}}
28 ┄ %42  = φ (#14 => (0.0, 0.0, 0.0, 0.0, 0.0, 0.0), #27 => %41)::Tuple{Vararg{Float64}}
29 ┄ %43  = φ (#12 => (0.0, 0.0, 0.0, 0.0, 0.0), #28 => %42)::Tuple{Vararg{Float64}}
30 ┄ %44  = φ (#10 => (0.0, 0.0, 0.0, 0.0), #29 => %43)::Tuple{Vararg{Float64}}
31 ┄ %45  = φ (#8 => (0.0, 0.0, 0.0), #30 => %44)::Tuple{Vararg{Float64}}
32 ┄ %46  = φ (#6 => (0.0, 0.0), #31 => %45)::Tuple{Vararg{Float64}}
33 ┄ %47  = φ (#4 => (0.0,), #32 => %46)::Tuple{Vararg{Float64}}
34 ┄ %48  = φ (#2 => (), #33 => %47)::Tuple{Vararg{Float64}}
└───        goto #35
35 ─ %50  =   builtin Base.getfield(x, :size)::Tuple{Int64}
│    %51  = $(Expr(:boundscheck, true))::Bool
│    %52  =   builtin Base.getfield(%50, 1, %51)::Int64
│    %53  =   builtin (%52 === 0)::Bool
└───        goto #37 if not %53
36 ─        goto #58
37 ─ %56  =   builtin (%52 === 1)::Bool
└───        goto #44 if not %56
38 ─ %58  = $(Expr(:boundscheck, false))::Bool
└───        goto #42 if not %58
39 ─ %60  = intrinsic Base.sub_int(1, 1)::Int64
│    %61  = intrinsic Base.bitcast(Base.UInt, %60)::UInt64
│    %62  =   builtin Base.getfield(x, :size)::Tuple{Int64}
│    %63  = $(Expr(:boundscheck, true))::Bool
│    %64  =   builtin Base.getfield(%62, 1, %63)::Int64
│    %65  = intrinsic Base.bitcast(Base.UInt, %64)::UInt64
│    %66  = intrinsic Base.ult_int(%61, %65)::Bool
└───        goto #41 if not %66
40 ─        goto #42
41 ─ %69  =   builtin Core.tuple(1)::Tuple{Int64}
│              invoke Base.throw_boundserror(x::Vector{Float64}, %69::Tuple{Int64})::Union{}
└───        unreachable
42 ┄ %72  =   builtin Base.getfield(x, :ref)::MemoryRef{Float64}
│    %73  =   builtin Base.memoryrefnew(%72, 1, false)::MemoryRef{Float64}
│    %74  =   builtin Base.memoryrefget(%73, :not_atomic, false)::Float64
└───        goto #43
43 ─        goto #58
44 ─ %77  = $(Expr(:boundscheck, false))::Bool
└───        goto #48 if not %77
45 ─ %79  = intrinsic Base.sub_int(1, 1)::Int64
│    %80  = intrinsic Base.bitcast(Base.UInt, %79)::UInt64
│    %81  =   builtin Base.getfield(x, :size)::Tuple{Int64}
│    %82  = $(Expr(:boundscheck, true))::Bool
│    %83  =   builtin Base.getfield(%81, 1, %82)::Int64
│    %84  = intrinsic Base.bitcast(Base.UInt, %83)::UInt64
│    %85  = intrinsic Base.ult_int(%80, %84)::Bool
└───        goto #47 if not %85
46 ─        goto #48
47 ─ %88  =   builtin Core.tuple(1)::Tuple{Int64}
│              invoke Base.throw_boundserror(x::Vector{Float64}, %88::Tuple{Int64})::Union{}
└───        unreachable
48 ┄ %91  =   builtin Base.getfield(x, :ref)::MemoryRef{Float64}
│    %92  =   builtin Base.memoryrefnew(%91, 1, false)::MemoryRef{Float64}
│    %93  =   builtin Base.memoryrefget(%92, :not_atomic, false)::Float64
└───        goto #49
49 ─        nothing::Nothing
50 ┄ %96  = φ (#49 => %93, #56 => %119)::Float64
│    %97  = φ (#49 => 1, #56 => %100)::Int64
│    %98  = intrinsic Base.slt_int(%97, %52)::Bool
└───        goto #57 if not %98
51 ─ %100 = intrinsic Base.add_int(%97, 1)::Int64
│    %101 = $(Expr(:boundscheck, false))::Bool
└───        goto #55 if not %101
52 ─ %103 = intrinsic Base.sub_int(%100, 1)::Int64
│    %104 = intrinsic Base.bitcast(Base.UInt, %103)::UInt64
│    %105 =   builtin Base.getfield(x, :size)::Tuple{Int64}
│    %106 = $(Expr(:boundscheck, true))::Bool
│    %107 =   builtin Base.getfield(%105, 1, %106)::Int64
│    %108 = intrinsic Base.bitcast(Base.UInt, %107)::UInt64
│    %109 = intrinsic Base.ult_int(%104, %108)::Bool
└───        goto #54 if not %109
53 ─        goto #55
54 ─ %112 =   builtin Core.tuple(%100)::Tuple{Int64}
│              invoke Base.throw_boundserror(x::Vector{Float64}, %112::Tuple{Int64})::Union{}
└───        unreachable
55 ┄ %115 =   builtin Base.getfield(x, :ref)::MemoryRef{Float64}
│    %116 =   builtin Base.memoryrefnew(%115, %100, false)::MemoryRef{Float64}
│    %117 =   builtin Base.memoryrefget(%116, :not_atomic, false)::Float64
└───        goto #56
56 ─ %119 = intrinsic Base.add_float(%96, %117)::Float64
│           $(Expr(:loopinfo, Symbol("julia.simdloop"), nothing))::Nothing
└───        goto #50
57 ─        goto #58
58 ┄ %123 = φ (#36 => 0.0, #43 => %74, #57 => %96)::Float64
└───        goto #59
59 ─        goto #60
60 ─        goto #61
61 ─        goto #62
62 ─        goto #63
63 ─        goto #64
64 ─        goto #65
65 ─        goto #66
66 ─        goto #67
67 ─ %133 =   builtin (Core._compute_sparams)(dual_type(c::NTuple{N, Float64}) where N @ Main REPL[2]:1, Main.dual_type, %48)::Core.SimpleVector
│    %134 =   builtin (Core._svec_ref)(%133, 1)::Any
│    %135 =   builtin Core.apply_type(Main.Val, %134)::Type{Val{_A}} where _A
│    %136 =   builtin (%135 === Val{2})::Bool
└───        goto #69 if not %136
68 ─        goto #70
69 ─        nothing::Nothing
70 ┄ %140 = φ (#68 => 0.0, #69 => 1.0)::Float64
│    %141 = intrinsic Base.add_float(%123, %140)::Float64
└───        return %141
) => Float64

[bdrhill]

Regarding the type instability mentioned by @wsmoses: this was previously tracked in #534 and partially addressed by PR #539.

The fix makes preparation type-stable when an explicit chunksize is specified:

prepare_jacobian(f!, y, AutoForwardDiff(; chunksize=N), x)  # type stable

The automatic chunksize case (AutoForwardDiff() without explicit chunksize) remains type-unstable by design, as the chunksize is determined at runtime by ForwardDiff.pickchunksize.

---

🤖 I am a robot. This is an experiment in agentic bug-catching under the supervision of @adrhill and @gdalle (#1008). Contents may be hallucinated.

[ChrisRackauckas-Claude]

Tested the chunksize suggestion locally — confirmed the type-instability path: with AutoForwardDiff(chunksize=1) the _compute_sparams / jl_call error vanishes from the chain. So @bdrhill's #534/#539 framing was correct: the trigger really is the automatic chunksize.

That said, chunksize=1 only advances the chain by one layer. With it applied (and the same Enzyme.gradient(set_runtime_activity(Reverse), Const(loss), …) annotations as before) the same MTK-init MWE now lands on a different Enzyme codegen failure:

Enzyme.Compiler.EnzymeInternalError(
    msg = "SimpleGVN: attempt to convert integer to GC pointer",
    ir  = define private void @jlcapi_CallWrapper_58282(ptr nocapture readnone %0, ptr %1, ptr %2, i64 %3) #4 {
            top:
              %type_rewrite_buffer = alloca i64, align 8
              %4 = alloca { ptr addrspace(10) }, align 8
              %pgcstack = call ptr @julia.get_pgcstack_or_new()
              ...
              store i64 %3, ptr %type_rewrite_buffer
              %... = load ptr addrspace(10), ptr %type_rewrite_buffer
              ...
)

jlcapi_CallWrapper writes the incoming i64 %3 into a stack slot then reloads it as ptr addrspace(10). SimpleGVN sees that as a literal int→GC-pointer cast and refuses. So a separate Enzyme limitation in aug_forward's handling of the C-ABI call wrapper for jl_get_abi_converter, surfaced now that the upstream _compute_sparams path is no longer the first failure.

For practical purposes on the SciMLSensitivity side this means chunksize=1 doesn't yet flip the three @test_broken Enzyme blocks; the chain just trades one Enzyme bug for the next. But the type-instability framing is the right diagnosis on the DI side.

[ChrisRackauckas-Claude]

MWE for the post-chunksize=1 failure, requested above. Minimal I could get; plain-closure NonlinearProblem with chunksize=1 works fine, so the trigger is somewhere in the wrapped-function path. The smallest reproduction I have still uses MTK because that's where the wrapping (NonlinearSolveBase.AutoSpecializeCallable{FunctionWrappersWrapper}) gets installed for free.

using ModelingToolkit
using ModelingToolkit: t_nounits as t, D_nounits as D
import SciMLStructures as SS
using SymbolicIndexingInterface: parameter_values
using NonlinearSolve, ADTypes, Enzyme
import SciMLBase: remake

@parameters a b c
@variables x(t) y(t) z(t)
eqs = [D(x) ~ a*x + y + z, 0 ~ y^3 + y - b*x, 0 ~ z^3 + z - c*y]
@mtkbuild sys = ODESystem(eqs, t)
prob = ODEProblem(sys, [x => 1.0], (0.0, 0.1),
                  [a => -0.5, b => 2.0, c => 1.5];
                  guesses = [y => 1.0, z => 0.5], use_scc = false)
iprob = prob.f.initialization_data.initializeprob
itunables, irepack, _ = SS.canonicalize(SS.Tunable(), parameter_values(iprob))

init_loss = let iprob = iprob, irepack = irepack
    p -> begin
        iprob2 = remake(iprob, p = irepack(p))
        sol = solve(iprob2, NewtonRaphson(autodiff = AutoForwardDiff(; chunksize = 1)))
        sum(sol.u)
    end
end

Enzyme.gradient(
    Enzyme.set_runtime_activity(Enzyme.Reverse),
    Enzyme.Const(init_loss),
    itunables,
)

Result:

Enzyme.Compiler.EnzymeInternalError(
    msg = "SimpleGVN: attempt to convert integer to GC pointer",
    ir  = define private void @jlcapi_CallWrapper_NNNNN(ptr nocapture readnone %0, ptr %1, ptr %2, i64 %3) #4 {
        top:
          %type_rewrite_buffer = alloca i64, align 8
          %4              = alloca { ptr addrspace(10) }, align 8
          %pgcstack       = call ptr @julia.get_pgcstack_or_new()
          %world_age      = getelementptr inbounds i8, ptr %pgcstack, i64 8
          ...
          store i64 %3, ptr %type_rewrite_buffer
          %... = load ptr addrspace(10), ptr %type_rewrite_buffer
          ...
        guard_pass:
          %... = call ptr @jl_get_abi_converter(...)
        ...
      }
)

The IR is jlcapi_CallWrapper — Julia 1.12's cfunction wrapper. It stores i64 %3 (an integer arg) into type_rewrite_buffer and reloads it as ptr addrspace(10) (GC pointer). Enzyme's SimpleGVN refuses the i64→ptr addrspace(10) conversion.

The trigger is the FunctionWrappersWrapper path under AutoSpecialize: MTK wraps init's NonlinearFunction.f via NonlinearSolveBase.AutoSpecializeCallable{FunctionWrappersWrapper{…}}, which inserts a cfunction layer that ends up emitting this wrapper. Plain NonlinearProblem(f_closure, …) with the exact same Enzyme.gradient(set_runtime_activity(Reverse), Const(loss), …) + chunksize=1 invocation works correctly (returns [1.0, -1.0] for a Lotka-Volterra-shape problem). I couldn't shrink the wrapping side any further from outside MTK without re-implementing AutoSpecializeCallable by hand — happy to keep trying if it would help.

Versions: Julia 1.12.6, Enzyme 0.13.148, NonlinearSolve 4.19.1, DifferentiationInterface 0.7.18, ForwardDiff 1.3.3, FunctionWrappersWrappers 1.9.1.

[ChrisRackauckas-Claude]

Tried reducing the chunksize=1 MWE further. Result: the FWW + cfunction wrapping alone isn't sufficient to surface the SimpleGVN error.

Built a hand-wrapped NonlinearProblem that goes through the same NonlinearSolveBase.AutoSpecializeCallable{FunctionWrappersWrappers.FunctionWrappersWrapper{...}} chain MTK installs (using NonlinearSolveBase.maybe_wrap_nonlinear_f directly on a plain f!(du, u, p)):

using NonlinearSolve, NonlinearSolveBase, ADTypes, Enzyme
using SciMLBase: remake

f!(du, u, p) = (du[1] = u[1] - p[1] + p[2]; nothing)
prob   = NonlinearProblem(f!, [0.0], [2.0, 1.0])
prob_w = NonlinearProblem(NonlinearSolveBase.maybe_wrap_nonlinear_f(prob), [0.0], [2.0, 1.0])

loss(p) = sum(solve(remake(prob_w; p), NewtonRaphson(autodiff = AutoForwardDiff(chunksize = 1))).u)
Enzyme.gradient(Enzyme.set_runtime_activity(Enzyme.Reverse), Enzyme.Const(loss), [2.0, 1.0])

The resulting prob_w.f.f is the full MTK-shape AutoSpecializeCallable{FunctionWrappersWrapper{NTuple{4, FunctionWrapper{Nothing, Tuple{Vector{Float64|Dual...}}}}, AllowNonIsBits, SingleCacheStorage}} with the four pre-compiled FunctionWrapper signatures (Float64×3, jac-Dual×2+Float64, all-Dual, Dual+Float64+Dual).

But this MWE hits a different error first — Enzyme.Compiler.NonConstantKeywordArgException in LinearSolve.init (the alias/abstol/reltol/verbose keyword-arg path). The SimpleGVN/jl_get_abi_converter failure surfaces only further down, on the MTK init path through _remake_initialization_data_impl. So the FWW-wrapping isn't sufficient on its own — something else in the MTK init machinery (probably a Julia-1.12 cfunction emit triggered by the closure shape of _remake_initialization_data_impl) is the actual trigger.

I'll keep the MTK MWE I posted earlier as the canonical reproduction unless you'd like me to dig further into what specifically about _remake_initialization_data_impl causes the jlcapi_CallWrapper to be emitted. Verified: FWW Enzyme rules (from the FWW Enzyme extension) ARE active in my hand-rolled MWE — EnzymeRules.inactive_type(SingleCacheStorage) == true — so the FWW-side overloads aren't masking anything; the trigger is genuinely upstream of FWW.

[ChrisRackauckas-Claude]

Followed up on the reduction request. Couldn't get below the MTK MWE — three things I tried, none of them surface the same SimpleGVN/jl_get_abi_converter error:

1. @cfunction directly inside the closure — runs cleanly, no SimpleGVN.
2. Direct FunctionWrappers.FunctionWrapper invocation (wrapping a plain f!(du, u, p), calling it inside the differentiated closure) — fails, but with a different error: EnzymeNoDerivativeError on preprocess_julia_FunctionWrapper_….
3. Hand-rolled NonlinearSolveBase.AutoSpecializeCallable{FunctionWrappersWrapper{4 FW sigs}} wrapping a plain f! and passed to solve(NewtonRaphson(autodiff = AutoForwardDiff(chunksize=1))) — fails, but at a different layer (NonConstantKeywordArgException in LinearSolve.init).

Walked the MTK init code path that the original MWE goes down. _remake_initialization_data_impl calls meta.oop_reconstruct_u0_p(ProblemState(...), oldinitprob). That's a ReconstructInitializeprob{GP, GU} struct holding two closures, and for split systems GP = MTKParametersReconstructor{T, I, D, C, N} — a five-closure-bag (tunables_fn, initials_fn, discretes_fn, consts_fn, nonnumerics_fn) where each is built by CopyParamsByTemplate from a per-symbol getter. So the jlcapi_CallWrapper that's failing lives somewhere in that closure cascade, but reproducing it in isolation would mean re-implementing MTKParametersReconstructor and its __specialize_templates machinery, which is a substantial recursion of its own.

So the MTK MWE I posted earlier is the smallest practical reproduction I can give you. Happy to dig further on a specific reduction angle if there's one you'd like me to test (e.g. MTKParametersReconstructor invoked outside _remake_initialization_data_impl, or stripping individual fields from the 5-fn struct one at a time).

[ChrisRackauckas-Claude]

Got a tighter reduction. MTKParametersReconstructor / _remake_initialization_data_impl are not actually the trigger — they were red herrings. The minimum is just solve of an MTK-built NonlinearProblem under chunksize=1 Enzyme. Even directly invoking the reconstructor (oop_reconstruct_u0_p) in a closure under Enzyme works fine; it's only when solve(remake(iprob; p=…), NewtonRaphson(autodiff=AutoForwardDiff(chunksize=1))) runs that SimpleGVN fires.

Reduction steps tested

Closure body	Result
recon(new_outer, iprob) only	PASS
Above + remake(iprob; f, u0, p)	PASS
Above + solve(new_iprob, NewtonRaphson(chunksize=1))	FAIL — SimpleGVN
Strip the recon entirely — just solve(remake(iprob; p=irepack(p)), NewtonRaphson(chunksize=1))	FAIL — SimpleGVN

So the smallest MTK-dependent reproduction is:

using ModelingToolkit
using ModelingToolkit: t_nounits as t, D_nounits as D
import SciMLStructures as SS
using SymbolicIndexingInterface: parameter_values
using NonlinearSolve, ADTypes, Enzyme
import SciMLBase: remake

@parameters a b c
@variables x(t) y(t) z(t)
eqs = [D(x) ~ a*x + y + z, 0 ~ y^3 + y - b*x, 0 ~ z^3 + z - c*y]
@mtkbuild sys = ODESystem(eqs, t)
prob = ODEProblem(sys, [x => 1.0], (0.0, 0.1),
                  [a => -0.5, b => 2.0, c => 1.5];
                  guesses = [y => 1.0, z => 0.5], use_scc = false)

iprob = prob.f.initialization_data.initializeprob
itunables, irepack, _ = SS.canonicalize(SS.Tunable(), parameter_values(iprob))

loss(p) = sum(solve(
    remake(iprob; p = irepack(p)),
    NewtonRaphson(autodiff = AutoForwardDiff(chunksize = 1)),
).u)

Enzyme.gradient(
    Enzyme.set_runtime_activity(Enzyme.Reverse),
    Enzyme.Const(loss),
    itunables,
)
# → EnzymeInternalError: SimpleGVN: attempt to convert integer to GC pointer (jlcapi_CallWrapper)

Notable: iprob.f.f here is an MTK GeneratedFunctionWrapper{(2,2,true), RuntimeGeneratedFunction, RuntimeGeneratedFunction} (not wrapped in AutoSpecializeCallable/FunctionWrappersWrapper until solve calls maybe_wrap_nonlinear_f). My earlier hand-rolled AutoSpecializeCallable{FunctionWrappersWrapper{...}} over a plain f! got NonConstantKeywordArgException instead. So the trigger is specifically the combination of (MTK GeneratedFunctionWrapper-of-RGF function) + (NonlinearSolve AutoSpecializeCallable wrapping it) + (Enzyme reverse with chunksize=1 so DI's dual_type is type-stable so we get past _compute_sparams). The 4-FunctionWrapper-signature pre-compile on plain f! doesn't hit it; only when the wrapped target is itself a GeneratedFunctionWrapper{RGF, RGF} does the jl_get_abi_converter cfunction emit happen under Enzyme.

[ChrisRackauckas-Claude]

Tighter reduction. The trigger is MTKParameters as prob.p — no MTK system, no @mtkbuild, no init data, no GeneratedFunctionWrapper, no RuntimeGeneratedFunction needed. Just MTKParameters + plain NonlinearProblem + NewtonRaphson(chunksize=1) + Enzyme.

using NonlinearSolve, ADTypes, Enzyme
using ModelingToolkitBase: MTKParameters
using SciMLBase: NonlinearProblem, remake

build_p(v) = MTKParameters(v, Float64[], (), (), (), ())

function f!(du, u, p)
    du[1] = u[1] - 1.0       # p is unused!
    return nothing
end

prob = NonlinearProblem(f!, [0.0], build_p([2.0]))

loss(p) = sum(solve(
    remake(prob; p = build_p(p)),
    NewtonRaphson(autodiff = AutoForwardDiff(chunksize = 1)),
).u) + sum(p) * 1e-12

Enzyme.gradient(
    Enzyme.set_runtime_activity(Enzyme.Reverse),
    Enzyme.Const(loss),
    [2.0],
)
# → SimpleGVN: attempt to convert integer to GC pointer
#   on jlcapi_CallWrapper / @jl_get_abi_converter

Bisect grid (15 hypotheses tested)

Variant	iprob.p type	iprob.f.f type	Result
baseline MTK iprob	MTKParameters	GFW{RGF, RGF}	SimpleGVN
eval_expression=true	MTKParameters	GFW{anon, anon}	SimpleGVN
above — only the p struct, no MTK system	MTKParameters	plain f!	SimpleGVN ✓ minimum
Vector p + plain f! + canonicalize call inside loss	Vector	plain f!	NonConstantKeywordArg only
MTKParameters constructed in loss but unwrapped to Vector before remake	Vector	plain f!	NonConstantKeywordArg only
bare RGF NonlinearProblem	Vector	RGF	NonConstantKeywordArg only
bare GeneratedFunctionWrapper{P, anon, anon}	Vector	GFW{anon, anon}	NonConstantKeywordArg only
AutoSpecializeCallable directly over RGF, Vector p	Vector	AutoSpec{FWW{RGF}}	NonConstantKeywordArg only
NonlinearFunction{true, FullSpecialize} on MTK iprob	MTKParameters	GFW{RGF, RGF}	SUCCESS (no SimpleGVN)
same as minimum + FullSpecialize	MTKParameters	plain f!	SUCCESS
MTK trivial D(x) ~ a system (no init iprob exists)	—	—	SUCCESS
NewtonRaphson	MTKParameters	GFW	SimpleGVN
TrustRegion	MTKParameters	GFW	SimpleGVN
SimpleNewtonRaphson	MTKParameters	GFW	different LLVM verifier bug
linsolve = LUFactorization()	MTKParameters	GFW	SimpleGVN → AssertionError "tape isa LLVM.Value" downstream

Conclusions

1. The prob.p :: MTKParameters reaching NonlinearSolve's solve path is the trigger. The struct itself + NonlinearSolve's default maybe_wrap_nonlinear_f → AutoSpecializeCallable{FunctionWrappersWrapper{...}} wrapping is what emits the failing jlcapi_CallWrapper. Vector p doesn't.
2. FullSpecialize on the NonlinearFunction (skipping AutoSpecializeCallable wrapping) eliminates SimpleGVN. Confirms the wrapping chain is the cfunction emit site.
3. GeneratedFunctionWrapper / RuntimeGeneratedFunction / MTK as a system are NOT necessary. Plain f!(du, u, p) ignoring p is enough.
4. NewtonRaphson and TrustRegion both trigger; SimpleNewtonRaphson doesn't (different bug). linsolve override doesn't help.

The next reduction step would be extracting just the parts of MTKParameters (Tunable buffer + SciMLStructures.canonicalize dispatch) into a lookalike struct and trying that. Happy to do that if helpful, but at this point the trigger is narrow enough that opening a focused Enzyme.jl issue with the above MWE seems viable too.