Repository navigation
Sign- and zero-extend 8- and 16-bit arguments to declared functions - #369
Merged
Merged
Conversation
clang-compiled callees on x86-64 SysV trust the caller to have extended them; tslang passed bare i8/i16, so int8_t -5 arrived as 251. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ASDAlexander77
force-pushed
the
small-int-arg-extension
branch
from
September 26, 2026 16:41
cbe60aa to
bc88097
Compare
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
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.
On x86-64 Linux, a call from tslang into C that passes an 8- or 16-bit integer or a
boolcould hand the C function a wrong value. tslang never emittedsignext/zeroext; nothing underlib/TypeScriptset either.Found by #367's end-to-end bindgen test on Linux CI (run 36246544195):
fx_widen_s8(int8_t v) { return v; }, built by clang at-O2, returned 251 for -5.Cause
On x86-64 SysV, clang-compiled code expects whoever hands over a small integer to have extended it to 32 bits:
LLVM does that extension only when the parameter or result is marked
signext/zeroext. tslang passed the barei8, so the callee read -5's 8 bits as 251 in a 32-bit register.u1665535 came out right only because its zero extension is the same number.On Windows x64 the callee extends, so the bug never showed there.
Fix
FuncOpLowering(LowerToLLVM.cpp) now marks the parameters and result of a declaration, a function with no body:s8/s16:signext;u8/u16/boolean:zeroext.A direct call takes the callee declaration's attributes, so the caller now extends:
movl $-5, %edifortake_s8(-5), checked with--emit=asm --mtriple=x86_64-unknown-linux-gnu.Not changed
signextparameter makes the callee trust its caller to have extended. tslang's indirect calls (closures, vtables, hybrid functions) carry no call-site attributes, so marking definitions would create new miscompiles in pure tslang code. So a tslang callback that C calls with a small integer, or whose small result C reads, is still unmarked.i8/i16are left alone, since no type says which extension they need. tsbindgen emitssN/uN.Tests
test-compile-small-int-ext-*: eight IR checks onsmall-int-ext/declare.ts, coverings8,s16,u8,u16,bool, ans8and au16result, ands32left unmarked.s32control passed both before and after.test-bindgen-plainandtest-bindgen-namespacenow pass, including thenarrowrow that failed without this fix.🤖 Generated with Claude Code