chore(release): v0.50.0 — cross-backend verified core + the allocator endgame begins#845
Merged
Conversation
… endgame begins (7-lane hub) Wave 1: VCR-RA-003 RV32 alloc-validator (#815/#821), VCR-RA-003 ARM optimized-path joins deferred (#819→redo), VCR-WASM i64 batch Qed 585→591 (#814). Wave 2: RV32 memory.size/grow parity (#841), WCET ph5 data-dep masked-ceiling certs (#839), aarch64 void-block CF (#842), soundness sweep (WIP deferred), native i64 rem_u/rem_s modeling via ordeal-0.12 Urem/bvsrem (#844), #837 frame-backing i64-param, and the headline VCR-DEC-001 graph-colouring allocator spike flag-off (#843) — validated by VCR-RA-003, flag-off byte-identical. Plus ci auto-merge for dependabot (#838). Pin sweep 0.49.0→0.50.0; status.json/FEATURE_MATRIX regenerated; 25/25 claims; frozen 10/10. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YJK5LZZEkV5smCY1jKn18L
… — solver hang #844 replaced the I64RemU/I64RemS HAVOC in arm_semantics with a real 64-bit `dividend.bvsrem/bvurem(&divisor)`. That query is the hardest bitvector class there is, and it HANGS both solvers: the pure-Rust ordeal default (→ the CI "Test" job) and the Z3 differential (→ the "Z3 Verification" job). Both jobs have run 4-6h and timed out on EVERY CI run since #844 landed — the last green CI on main was 2026-07-20 (61acec9). Confirmed independently: the L8 rem test produced no output (hung) in salvage, and a separate agent's full workspace run reached 107 test binaries / 0 failures and stalled only on this synth-verify rem SMT test. This restores the pre-#844 havoc model (byte-invisible — verify-only, no codegen change, frozen anchors untouched by construction) to un-hang CI and unblock the v0.50.0 tag. Native i64 rem re-lands in v0.51 behind a per-query solver timeout so a hard bvurem degrades to `unknown` instead of hanging the whole suite. Tracking: #848 (re-land behind a per-query solver timeout). The term.rs/solver.rs BvTerm::Urem enum arms stay — they are the #836 ordeal-0.12 enum-completeness handlers (harmless; nothing in verify now generates the variant). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YJK5LZZEkV5smCY1jKn18L
…GS CI ROOT CAUSE of the 4-6h CI hangs (both the ordeal-default Test job and the Z3 Verification job) that have red-mained `main` since 2026-07-20: the ordeal 0.9.1 -> 0.12.0 dependabot bump (#825). 0.12 has a solver-performance regression on bvsrem/bvsdiv that hangs div/rem trap-preservation VCs — even the pre-existing 32-bit `rems_single_zero_guard_is_exactly_right` (I32RemS Sdiv+Mls, #753/v0.43) hangs >240s on 0.12 but runs <1s on 0.9.1. The last GREEN CI on main (61acec9, 2026-07-20 21:45:27) used ordeal 0.9.1 — #825 merged 3 seconds later. NO commit with ordeal 0.12 has ever passed CI; every subsequent lane auto-merged on the required-gate subset while Test/Z3 timed out. #844 (native i64 rem via 0.12 bvsrem/bvurem) made it far worse and was reverted (db0f1f2, re-land #848); this pin is the actual fix. Changes: - crates/synth-verify/Cargo.toml: ordeal "0.12.0" -> "=0.9.1" (exact last-green pin; do-not-bump note added). Cargo.lock: ordeal + ordeal-lrat 0.12.0 -> 0.9.1. - Remove the four #836 `BvTerm::Urem` match arms (term.rs x3, z3-gated solver.rs x1) — that variant exists only in ordeal 0.12. Verified: `cargo test -p synth-verify` = 236 tests, 0 failed, ~41s (was >6h timeout on 0.12). Byte-invisible — verify-only, no codegen change, frozen anchors untouched by construction. Follow-ups (tracked, non-blocking): report the bvsrem/bvsdiv regression upstream to ordeal; tighten .github/workflows/dependabot-auto-merge.yml (#838) to HOLD 0.x MINOR bumps (0.9->0.12 is breaking by 0.x semver but dependabot classified it "minor" and auto-merged it). See #849. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YJK5LZZEkV5smCY1jKn18L
… =0.9.1 pin (#849) #844's native i64 rem value model was reverted (it depended on ordeal 0.12, which has the bvsrem/bvsdiv perf regression that hangs CI). The real v0.50.0 change is the ordeal =0.9.1 pin. Do not advertise a reverted feature. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YJK5LZZEkV5smCY1jKn18L
…disasm text The `rv32 memory.size / memory.grow execution oracle` (#841, VCR-SEL-005) has FAILED on every CI run it actually executed — "FAIL — no symbol for export sz ([])" — the `syms` map came back EMPTY on the ubuntu runner. It located function offsets by regex-parsing `synth disasm` TEXT (`^([0-9a-f]{8}) <(\w+)>:`), which matched nothing on Linux for the `--relocatable` RISC-V object even though it matched on macOS. It was merged ungated: main CI has been timing out since 2026-07-20 (ordeal-0.12 hang, #849), so this job was CANCELLED on every prior run and its true `failure` never surfaced until the hang was fixed. The codegen is correct — the oracle passes in every local configuration (fresh binary, old + latest wasmtime 47.0.1). Only the symbol LOOKUP was host-fragile. Fix: read function offsets from the ELF SYMBOL TABLE via pyelftools (`.symtab`, `st_value` = offset within `.text` for a relocatable object) — host-independent, the documented differential-harness lesson. The `.text` bytes were already read via pyelftools; this just does the addresses the same way. Drop the now-unused `re` import. Verified: same addresses, oracle still PASS locally (sz=3/grow0=3/grow2=-1). No codegen/frozen change. Follow-up (non-blocking): 10 other repro oracles still regex-parse disasm text (add_imm_large, bulk_memory_374, control_step_riscv, div_const, ...) — they pass on CI today but carry the same latent host-dependency; harden them to symtab. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YJK5LZZEkV5smCY1jKn18L
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
v0.50.0 release assembly. 7 lanes on main (#840/#841/#842/#843/#844 + #815/#821/#814/#839): the RV32 alloc-validator, RV32 memory parity, aarch64 CF, native i64 rem_u modeling, WCET ph5, frame-backing i64-param, and the headline VCR-DEC-001 graph-colouring allocator spike (flag-off, validated by VCR-RA-003).
Release mechanics: pin sweep 0.49.0→0.50.0 (workspace + path-deps + MODULE.bazel + npm), CHANGELOG [0.50.0] with all 7 lane entries + headline, regenerated status.json/FEATURE_MATRIX (Qed 591). 25/25 claims, frozen 10/10, fmt clean.
Deferred (honest): #819 VCR-RA-003 optimized-path joins (redo, task #57), L7 soundness sweep WIP (unverified, preserved on feat/50-soundness-sweep).
🤖 Generated with Claude Code