Lots of "function cannot be proven read-only" failures suddenly popping up

[ChrisRackauckas]

  Function argument passed to autodiff cannot be proven readonly.
  If the the function argument cannot contain derivative data, instead call autodiff(Mode, Const(f), ...)
  See https://enzyme.mit.edu/index.fcgi/julia/stable/faq/#Activity-of-temporary-storage for more information.
  The potentially writing call is   store {} addrspace(10)* %.fca.0.1.extract, {} addrspace(10)** %.fca.0.1.gep, align 8, !dbg !9, !noalias !21, using   %.fca.0.1.gep = getelementptr inbounds { { {} addrspace(10)*, {} addrspace(10)*, {} addrspace(10)*, {} addrspace(10)*, double }, [1 x i8] }, { { {} addrspace(10)*, {} addrspace(10)*, {} addrspace(10)*, {} addrspace(10)*, double }, [1 x i8] }* %.innerparm, i64 0, i32 0, i32 1, !dbg !9

https://github.com/SciML/OrdinaryDiffEq.jl/actions/runs/14539831121/job/40795481724?pr=2677#step:6:1384

https://github.com/SciML/OrdinaryDiffEq.jl/actions/runs/14539831121/job/40795503066?pr=2677#step:6:1392

Seen in multiple CIs. Any clue as to where this is coming from? Was there a recent breaking change in Enzyme?

[vchuravy]

There hasn't been a release of Enzyme.jl in a while, so unlikely?

Do you have an MWE?

[wsmoses]

@gdalle since the error is coming from DI

[gdalle]

@ChrisRackauckas did you ever use to run these tests with Enzyme being called directly through its native API? Or was Enzyme not tested at all in OrdinaryDiffEq before the DI overhaul? Most importantly, was there ever a point in time where these tests passed with the DI version?
If the answer to the last question is yes, and these tests only started failing today, then the culprit may be v0.18.36 of Enzyme (released today). So I wouldn't be so sure that the error is "coming from" DI, because the Enzyme bindings there haven't changed in a while. I presume something was altered in Enzyme regarding the way that functions are proven to be read-only?

DI offers a solution for this, which is to use AutoEnzyme(function_annotation=Enzyme.Const).
Now that my PR on exception types has been merged here, once Enzyme tags a new release, DI can use these types to provide nicer error hints for situations like the current one. But it doesn't change the fact that if these failures appeared today, Enzyme's behavior possibly changed for real, and DI may just be the messenger.

[wsmoses]

@gdalle That patch release basically only contained your error type PR. So if only that patch errors we can revert and re patch

[gdalle]

@ChrisRackauckas can you try your stuff with the previous version of Enzyme?

[wsmoses]

In the interim I reverted your error PR and re patched, since that is the only thing that touched anything vaguely related.

Once this is fixed @gdalle feel free to re open your PR (ideally with a test if it is the cause here)

[ChrisRackauckas]

These tests were passing until yesterday. I can try re-running the tests and see what happens with the new patch.

[wsmoses]

Seems like something is still sad. @gdalle can you get a reproducer without DI?

[gdalle]

Honestly this stuff is buried deep inside OrdinaryDiffEq, so the complexity doesn't come from DI itself. People used to the SciML stack will get it done much faster (also I'm on vacation this week). The truth is that, as more and more packages build upon DI, it will get harder and harder to boil everything down to a pure-Enzyme MWE. In this case, DI enables using Enzyme inside an ODE, so yes we see failures that we may not see outside of ODEs. Whether that's a good or a bad thing depends on your goals, but I'd say it's rather a good thing.

There were four PRs in the Enzyme v0.18.36 release, which seems to have caused the breakage. We've established it wasn't my error PR, which leaves only three. You don't have any clue which of those it could be and why? Or could it be a change in the jll instead of the Julia bindings? Or another dep?

[vchuravy]

The three PRs in v0.13.36 are:

• Avoid blow up of function pre-amble on higer order AD #2350 (Fairly straight-forward since it just filters out some pre-header instructions)
• Add common error supertype #2352 (Show to be unrelated (and I would have been very surprised if that was the case, since it was essentiatlly NFC))
• Handle recursive store for primitive types symbol/string #2342 Likely unrelated since it fixes an error during compilation

v0.13.35:

• Supports GPUCompiler 1.3

@ChrisRackauckas do you know which Enzyme version was used prior? It might be the case that there was an incompatibility somewhere else that blocked a couple of updates?

[wsmoses]

Yeah there similarly hasn't been a jll release for like a month (I just made one, after all this).

Maybe the GPUCompiler compat meant you had an old Enzyme?

[ChrisRackauckas]

If it helps, here's a CI run from 2 weeks ago:

https://github.com/SciML/OrdinaryDiffEq.jl/actions/runs/14367632037/job/40284221662

Looks like we had a lull for a week in that repo. The one from 2 weeks ago was fine, the Aqua tests fail for a different reason (just an unfinished PR branch), the Taylor one didn't run, and then the initdt one from 4 days ago

https://github.com/SciML/OrdinaryDiffEq.jl/actions/runs/14522100726/job/40745257902#step:6:1388

seems to be the first occurrence of it in our CI. So a good week in there, longer time frame than I'd thought, but maybe that helps narrow down package version changes?

The failing one was:

[a0c0ee7d] DifferentiationInterface v0.6.52
[7da242da] Enzyme v0.13.35
[f151be2c] EnzymeCore v0.8.8
[7cc45869] Enzyme_jll v0.0.173+

while the one that passed was:

[a0c0ee7d] DifferentiationInterface v0.6.50
[f151be2c] EnzymeCore v0.8.8
[7da242da] Enzyme v0.13.35
[7cc45869] Enzyme_jll v0.0.173+0

So my guess then is that it must be DI related?

[ChrisRackauckas]

Testing this theory here: SciML/OrdinaryDiffEq.jl#2680

[vchuravy]

Nothing weird is jumping at me JuliaDiff/DifferentiationInterface.jl@DifferentiationInterface-v0.6.50...DifferentiationInterface-v0.6.52