Fix i32 sign extension in MemoryPacking pass#8368
Open
sumleo wants to merge 1 commit intoWebAssembly:mainfrom
Open
Fix i32 sign extension in MemoryPacking pass#8368sumleo wants to merge 1 commit intoWebAssembly:mainfrom
sumleo wants to merge 1 commit intoWebAssembly:mainfrom
Conversation
kripken
reviewed
Feb 25, 2026
src/passes/MemoryPacking.cpp
Outdated
| if (offset && size) { | ||
| uint64_t offsetVal(offset->value.geti32()); | ||
| uint64_t sizeVal(size->value.geti32()); | ||
| uint64_t offsetVal(uint32_t(offset->value.geti32())); |
Member
There was a problem hiding this comment.
These can all be in the form auto x = value->getUnsigned(), which would be simpler.
Contributor
Author
There was a problem hiding this comment.
Done — switched to getUnsigned() for all four occurrences. Also cleaned up the existing uint32_t() casts on lines 458/461 to use getUnsigned() consistently.
Use getUnsigned() to properly zero-extend i32 values when computing memory.init offset and size. Previously, geti32() returned a signed int32_t that sign-extended when stored as uint64_t, causing values >= 0x80000000 to produce incorrect overflow detection and range calculations. Also clean up existing uint32_t() casts in the same function to use getUnsigned() consistently.
sumleo
force-pushed
the
fix-memory-packing-sign-extension
branch
from
0a19127 to
a3eb99c
Compare
kripken
approved these changes
Feb 25, 2026
Member
kripken
left a comment
kripken
left a comment
There was a problem hiding this comment.
lgtm, thanks!
Though before landing, I have a question for @tlively - how did we not see crashes with running this pass on memory64? All the places that assume a segment offset is 32-bit were wrong, weren't they?
And we do run this pass on memory64, each time e.g. emscripten compiles memory64 code?
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
2 participants
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.
Summary
geti32()results when assigned touint64_t/size_tin MemoryPacking passvisitMemoryInit(line 465-466):offsetValandsizeValsign-extend for values >=0x80000000, causing validmemory.initinstructions to be incorrectly replaced with trapscreateSplitSegments(line 713-714): same pattern corrupts start/end range calculation for segment splittingThe fix casts through
uint32_tbefore widening, consistent with the pattern already used at lines 458 and 461 in the same function.Test plan