Skip to content

fix: bump ordeal 0.9.1 → 0.14.0 — rem_s can now route through trap_gate - #290

Merged
avrabe merged 2 commits into
mainfrom
fix/ordeal-0.14-rem-s-gate
Jul 30, 2026
Merged

fix: bump ordeal 0.9.1 → 0.14.0 — rem_s can now route through trap_gate#290
avrabe merged 2 commits into
mainfrom
fix/ordeal-0.14-rem-s-gate

Conversation

@avrabe

@avrabe avrabe commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Completes the consumer side of ordeal#84 (= ordeal#72), and removes one blocker from #288.

The gap

ordeal < 0.10.0's trap_div(DivOp::RemS) wrongly included the INT_MIN/-1 overflow clause (WASM Core §4.4.1: only idiv_s traps there; irem_s(INT_MIN, -1) = 0, defined). So this gate falsely rejected the sound rem_s(INT_MIN,-1) → 0 fold as a phantom trap mismatch — which is why rem_s stayed on the per-pass static guard. ordeal fixed it in v0.10.0; this picks it up (0.14.0 current).

The un-pinning test is mutation-checked, not asserted

# ordeal 0.14.0:
test trap_gate::tests::rem_s_int_min_neg1_fold_is_accepted ... ok

# pin flipped back to ordeal 0.9.1:
FAILED — "rem_s(INT_MIN,-1) -> 0 is a sound fold and must be ACCEPTED
          (ordeal < 0.10.0 falsely rejected it), got RejectCounterexample([])"

That reproduces the historical false rejection exactly. The dual guard is included: a wrong-value rem_s fold (→ 1 instead of 0) is still rejected, so accepting the sound fold did not wave rem_s folds through.

Also fixed

div_define's doc comment described 0.9.1's bug as spec ("INT_MIN/-1 overflow for the signed ops" — it's div_s only).

Gate

Full loom-core suite with the verification feature: 655 tests, 0 failed. API compatible across ordeal 0.10–0.14 — no code changes needed beyond docs + tests.

What this does NOT do

#288's systemic finding stands: trap_gate is still never called by any pass (confirmed on ad39d1c — the only external reference is a test). This bump removes the rem_s blocker for that wiring; the wiring itself — a per-fold gate call inside constant_folding, with its cost/caching design questions — is its own effort and shouldn't ride along in a dependency bump.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EBJ6kdJ16E3hnsBbq9Lwf1

@avrabe

avrabe commented Jul 22, 2026

Copy link
Copy Markdown
Contributor Author

CI note: the two non-green checks are not caused by this PR. Rocq Formal Proofs fails on main's HEAD as well (verified on the current main commit — pre-existing), and Verification Gate (rivet-driven) was cancelled downstream of it. The 23 checks that exercise this change (build, loom-core suite incl. the new trap_gate tests, clippy, fmt) all pass. Leaving the merge decision to the maintainer since the red is main's, not this branch's — merging around it vs fixing Rocq first is a repo-health call I shouldn't make from a dependency bump.

@avrabe
avrabe force-pushed the fix/ordeal-0.14-rem-s-gate branch 2 times, most recently from dd15d85 to 9dbc72e Compare July 28, 2026 18:44
avrabe and others added 2 commits July 30, 2026 17:33
Completes the consumer side of ordeal#84 (= ordeal#72): ordeal < 0.10.0's
`trap_div(DivOp::RemS)` wrongly included the `INT_MIN/-1` overflow clause,
so this gate falsely REJECTED the sound `rem_s(INT_MIN,-1) -> 0` fold as a
phantom trap mismatch — which is why rem_s stayed on the per-pass static
guard. ordeal fixed it in v0.10.0 (spec-grounded, mutation-checked); this
bump picks it up (0.14.0 current).

The un-pinning test is MUTATION-CHECKED against the old pin, not asserted:
  - ordeal 0.14.0: rem_s_int_min_neg1_fold_is_accepted ... ok
  - ordeal 0.9.1:  FAILED — "got RejectCounterexample([])"
    (the phantom mismatch, reproduced exactly)
Plus the dual guard: a WRONG-value rem_s fold (-> 1 instead of 0) is still
rejected, so accepting the sound fold did not wave rem_s folds through.

Also corrects the div_define doc comment, which described 0.9.1's bug as
spec ("INT_MIN/-1 overflow for the signed ops" — it is div_s ONLY; WASM
defines rem_s(INT_MIN,-1) = 0).

Full loom-core suite with the verification feature: 655 tests, 0 failed.
API compatible across ordeal 0.10-0.14 (no code changes needed beyond
docs+tests).

NOT addressed here: #288's systemic finding that trap_gate is never called
by any pass. This bump removes the rem_s blocker for that wiring, but the
wiring itself (a per-fold gate call inside constant_folding, with its cost
and caching questions) is its own design effort — see #288 comment.

Refs: #288

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EBJ6kdJ16E3hnsBbq9Lwf1
…er-approx pin

Completes ordeal#84's consumer side AND removes the pin test that reddened
main. ordeal < 0.10.0's trap_div(RemS) carried the div_s INT_MIN/-1 overflow
disjunct, so the trap-gate falsely rejected the sound rem_s(INT_MIN,-1) -> 0
fold; rem_s stayed on the static #273 guard, pinned by
rem_s_int_min_is_over_approximated_rejected.

ordeal >= 0.10.0 dropped that disjunct for remainder (main now floats ordeal
0.17.0). The pin then asserted stale behaviour and FAILED on main. This:

- routes I32RemS/I64RemS in trap_backstop::div_meta so rem_s const-folds are
  trap-gated like the other three div/rem kinds (all four covered)
- removes the now-false pin rem_s_int_min_is_over_approximated_rejected
  (superseded by rem_s_int_min_neg1_fold_is_accepted + wrong-value dual),
  restoring the loom-core verification suite to green
- docs updated (rem_s: documented gap -> routed)

Verified on ordeal 0.17.0: loom-core --features verification --lib = 481
passed, 0 failed. (The wasm32-wasip2 build red on main is a separate,
pre-existing cranelift-isle MSRV issue, not touched here.)

Refs #279
@avrabe
avrabe force-pushed the fix/ordeal-0.14-rem-s-gate branch from 9dbc72e to 6a281f5 Compare July 30, 2026 15:39
@avrabe
avrabe merged commit 2c703a4 into main Jul 30, 2026
22 of 25 checks passed
@avrabe
avrabe deleted the fix/ordeal-0.14-rem-s-gate branch July 30, 2026 19:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant