[Issue Backlog] Backlog Analysis - 2026-03-17 #9019
Closed
Replies: 1 comment
-
|
This discussion has been marked as outdated by Issue Backlog Processor. A newer discussion is available at Discussion #9039. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Issue Backlog Analysis - 2026-03-17
Executive Summary
Issues Recommended for Closure
These issues appear to be resolved, no longer relevant, or fully answered.
smt.arith.solver=3(Floyd-Warshall) orsmt.arith.solver=2(Simplex). The follow-up discussion confirmed a benchmark showingarith.solver=3is 2× faster than the default. Remaining open as a performance tracking issue — consider closing if maintainers prefer.Potential Duplicates / Merge Candidates
These issues overlap with other open or closed issues and could be tracked together.
Cluster 1: String / Seq Invalid Model (Canonical: #8023)
The canonical issue #8023 tracks ongoing soundness violations in the string/sequence solver. These issues all produce invalid models or wrong
sat/unsatverdicts involving string or sequence operations:seq.++/ length constraintsseq.foldlunsound modelCluster 2: Float / FP Invalid Model (Canonical: #7162)
Cluster 3: JS/Node.js Thread Non-Termination (Canonical: #6512)
Cluster 4: arith.solver=6 Performance Regressions (Canonical: #4934)
Issues with Suggested Fixes
These issues have identifiable root causes or affected components.
#7730 — Spacer returns
satinstead of expectedunsatfp.spacer.native_mbp)src/muz/spacer/spacer_mev_array.cpp,src/muz/spacer/spacer_manager.cppnative_mbpcode path produces a spurious inductive invariant. Settingfp.spacer.native_mbp=falserestores correct behavior on 4.13.3; the workaround status on current HEAD is unknown. Assigned to@agurfinkel.#7593 — Invalid model with sequences: foldl, nth and ++
src/smt/theory_seq.cpp,src/smt/seq_axioms.cppseq.foldlencoding produces a satisfying assignment for which the model evaluator gives an inconsistent value (the model statesall = (seq.unit 4) ++ (seq.unit 0)butfinal = 6, which contradictsfoldlsemantics). This is part of the broader string/seq invalid-model cluster (Soundness issue in string logic #8023, invalid model issue on an incremental QF_SLIA formula #6982).#7592 — PartialOrder hangs when reasoning about bottom element
PartialOrderPython API + MBQI quantifier instantiationsrc/api/python/z3/z3.py(PartialOrderfunction),src/smt/smt_quantifier.cppPartialOrdergenerates quantified axioms (transitivity, antisymmetry, reflexivity) without explicit:patternhints. MBQI can loop on ground instances that need multi-step chaining. Explicit pattern annotations or aLinearOrder/ manual encoding avoids the loop (as shown in the issue). A fix could add patterns to thePartialOrder-generated axioms.#7538 —
produce-unsat-coresaffects convergencesrc/smt/smt_quantifier.cpp,src/smt/smt_relevancy.cppproduce-unsat-coresalters which clauses are marked relevant, changing which quantifier triggers fire. This is a side-effect of relevancy propagation (see also Unexpected proof failure due to minor input tweak #7444 for a detailed analysis by@CanCebeci). Not a correctness issue per se — when cores are enabled, Z3 producesunsat; without them it returnsunknown.#8023 — New segfault in latest comment (2026-03-16)
src/tactic/core/blast_term_ite_tactic.cpp,src/ast/rewriter/:fp.xform.bit_blast trueand nested quantifiers — unrelated to the string soundness bugs in the same issue. This segfault deserves its own issue for tracking.#7417 — Z3 returning wrong sat-answer (Horn + Arrays)
spacer_proof_utils.cpp)src/muz/spacer/spacer_proof_utils.cppline 358unsat(correct), but a debug-mode assertion violation remains inspacer_proof_utils.cpp:358("Arithmetic proof check failed"). The arithmetic Farkas coefficient check is failing on a valid proof. Likely the proof checker's Farkas lemma reconstruction is too strict. Assigned to@hgvk94,@agurfinkel.#7403 — Non-termination with mod0/div0 quantifiers
src/smt/smt_quantifier.cpp(mod (mod x y) y)triggers an instantiation that produces(mod (mod x y) y)again, creating a loop. Z3 does not detect this specific idempotency. The query can be solved without those quantifiers since Z3's arithmetic solver handles(mod (+ a b) b)natively. Removing the quantifiedmodaxioms and relying on the built-in theory solver should work.Issues Needing More Information
These issues lack sufficient detail to investigate or reproduce.
satinstead ofunsatfp.spacer.native_mbp=falsestill works as workaround in Z3 ≥ 4.15Notable Issues Deserving Attention
Issues that are particularly impactful, long-standing, or actively accumulating new evidence.
@agurfinkel; no resolution yetAutomated by Issue Backlog Processor — runs every 2 days. Previous run: 2026-03-15.
Beta Was this translation helpful? Give feedback.
All reactions