cfallin opened PR #14651 from cfallin:fix-x64-stack-frame-overflow to bytecodealliance:main:
Make some cases fallible and return
ImplLimitExceededon too-large stackslots.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease review the Bytecode Alliance's AI tool usage policy at
https://github.com/bytecodealliance/governance/blob/main/AI_TOOL_POLICY.mdPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
cfallin requested wasmtime-compiler-reviewers for a review on PR #14651.
cfallin requested fitzgen for a review on PR #14651.
:thumbs_up: alexcrichton submitted PR review.
alexcrichton has enabled auto merge for PR #14651.
alexcrichton added PR #14651 Cranelift: fix several integer-arithmetic overflows for large stack frames/stack slots. to the merge queue
github-actions[bot] added the label cranelift on PR #14651.
github-actions[bot] added the label cranelift:area:machinst on PR #14651.
github-actions[bot] added the label cranelift:area:aarch64 on PR #14651.
github-actions[bot] added the label cranelift:area:x64 on PR #14651.
:check: alexcrichton merged PR #14651.
alexcrichton removed PR #14651 Cranelift: fix several integer-arithmetic overflows for large stack frames/stack slots. from the merge queue
:memo: bjorn3 submitted PR review.
: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::MAXfor as long as you subtract i32::MAX again before dereferencing it. This rule would make it illegal for optimizations to foldiaddintostack_addrin 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