Enzyme v0.13.69 broke second-order differentiation with constant matrix

[gdalle]

Here's an MWE which fails on v0.13.69

(_Scratchpad) pkg> st
Status `~/Documents/GitHub/Julia/_Scratchpad/Project.toml`
  [7da242da] Enzyme v0.13.69

julia> using Enzyme, LinearAlgebra

julia> const A = ones(3, 3);

julia> f(x) = dot(x, A, x);

julia> x, dx = ones(3), ones(3);

julia> Enzyme.hvp(f, x, dx)  # should not be zero
3-element Vector{Float64}:
 0.0
 0.0
 0.0

and works on v0.13.68

(_Scratchpad2) pkg> st
Status `~/Documents/GitHub/Julia/_Scratchpad2/Project.toml`
⌃ [7da242da] Enzyme v0.13.68
Info Packages marked with ⌃ have new versions available and may be upgradable.

julia> using Enzyme, LinearAlgebra

julia> const A = ones(3, 3);

julia> f(x) = dot(x, A, x);

julia> x, dx = ones(3), ones(3);

julia> Enzyme.hvp(f, x, dx)
3-element Vector{Float64}:
 6.0
 6.0
 6.0

I spotted it because it broke the Enzyme tests for DI, so any help would be greatly appreciated.

Additional details:

julia> versioninfo()
Julia Version 1.11.6
Commit 9615af0f269 (2025-07-09 12:58 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: macOS (arm64-apple-darwin24.0.0)
  CPU: 11 × Apple M3 Pro
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, apple-m2)
Threads: 1 default, 0 interactive, 1 GC (on 5 virtual cores)

[gdalle]

Gentle bump on this @vchuravy since this seems like a bug introduced by either #2515 or #2516. Can you reproduce it?

[wsmoses]

likely we need to mark the relevant readonly attributes as not being preserved through reverse-mode differentiation

[wsmoses]

@gdalle would you be able to open a PR adding this as a test case.

Concurrently, we recently expanded our CI resource pool. Would you be interested in reviving the effort to add DI as reverse CI?

I think we're still going to need DI to dilute error messages to pure Enzyme variants if we were to making the DI CI blocking for a PR, but still it would be quite useful.

Caveat with the new runners, is that the environmental variable setup is a bit weird (but @giordano has found a good way to normalize these)

[wsmoses]

EnzymeAD/Enzyme#2423 I think should fix, if you want to try it out @gdalle

[wsmoses]

locally, confirmed that fixes jll will be incoming

[gdalle]

I don't know how to test changes outside of the Julia code locally, waiting on the jll to tell you for sure

[gdalle]

Thanks for the quick fix!

[gdalle]

@gdalle would you be able to open a PR adding this as a test case.

Sure, in which test file should this go?

Concurrently, we recently expanded our CI resource pool. Would you be interested in reviving the effort to add DI as reverse CI?

Yes, I can definitely do that

I think we're still going to need DI to dilute error messages to pure Enzyme variants if we were to making the DI CI blocking for a PR, but still it would be quite useful.

On the other hand I have no idea how to do this, so I think DI tests will have to be non-blocking for now. Reverse-generating Enzyme code (or more generally backend-specific code) is a huge headache, and I'm not sure it can even be done in a clever way (as in, without manually writing a wall-of-text error for every variant of every operator of every backend).
One thing that would help though is #2309, because it would significantly reduce the intrusiveness of the DI implem, and thus the effort to recover the Enzyme code.

[giordano]

Sure, in which test file should this go?

Create a new github actions workflow file and ping me so I can help you out. I think we'll run this only on one operating system (Linux), but possibly multiple Julia versions

[wsmoses]

the docs show how to make a custom jll, here: https://enzymead.github.io/Enzyme.jl/dev/dev_docs/