Stream: git-wasmtime

Topic: wasmtime / PR #14651 Cranelift: fix several integer-arith...


view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2026 at 01:44):

cfallin opened PR #14651 from cfallin:fix-x64-stack-frame-overflow to bytecodealliance:main:

Make some cases fallible and return ImplLimitExceeded on too-large stackslots.

<!--
Please make sure you include the following information:

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please review the Bytecode Alliance's AI tool usage policy at
https://github.com/bytecodealliance/governance/blob/main/AI_TOOL_POLICY.md

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2026 at 01:44):

cfallin requested wasmtime-compiler-reviewers for a review on PR #14651.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2026 at 01:44):

cfallin requested fitzgen for a review on PR #14651.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2026 at 02:49):

:thumbs_up: alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2026 at 02:49):

alexcrichton has enabled auto merge for PR #14651.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2026 at 03:57):

alexcrichton added PR #14651 Cranelift: fix several integer-arithmetic overflows for large stack frames/stack slots. to the merge queue

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2026 at 04:51):

github-actions[bot] added the label cranelift on PR #14651.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2026 at 04:51):

github-actions[bot] added the label cranelift:area:machinst on PR #14651.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2026 at 04:51):

github-actions[bot] added the label cranelift:area:aarch64 on PR #14651.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2026 at 04:51):

github-actions[bot] added the label cranelift:area:x64 on PR #14651.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2026 at 06:14):

:check: alexcrichton merged PR #14651.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2026 at 06:14):

alexcrichton removed PR #14651 Cranelift: fix several integer-arithmetic overflows for large stack frames/stack slots. from the merge queue

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2026 at 14:25):

:memo: bjorn3 submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 10 2026 at 14:25):

:speech_balloon: bjorn3 created PR review comment:

Why check the stack_addr offsets? I wouldn't expect it to be illegal to write stack_addr ss1, i32::MAX for as long as you subtract i32::MAX again before dereferencing it. This rule would make it illegal for optimizations to fold iadd into stack_addr in the general case. Unlike LLVM, Cranelift doesn't have a concept of inbounds pointer offsets where the pointer offset itself is already UB. And even if it were UB, I don't see why it should be statically rejected at compile time. UB in code that is not reachable at runtime is not a problem at all. Having a compiler error for conditional UB is a problem however.


Last updated: Oct 11 2026 at 04:10 UTC