Skip to content

Fix simd (default) build on clang >=16: undeclared libm fns in shim math.h - #1

Open
Leonardo-Rocha wants to merge 1 commit into
suirad:masterfrom
Qilvo-Tech:fix-simd-math-decls
Open

Fix simd (default) build on clang >=16: undeclared libm fns in shim math.h#1
Leonardo-Rocha wants to merge 1 commit into
suirad:masterfrom
Qilvo-Tech:fix-simd-math-decls

Conversation

@Leonardo-Rocha

@Leonardo-Rocha Leonardo-Rocha commented Jul 14, 2026

Copy link
Copy Markdown

Note: assisted by Claude Fable 5.

What

The bundled wasm-sse2 compat headers (emscripten's SSE2→wasm128 shims, under crates/box3d-sys/shims/include/wasm-sse2/) reference fabs / lrint / lrintf / llrint / llrintf in their inline conversion helpers. But the freestanding shim math.h never declares them, and stdb.rs exports only the float libm functions (sinflogf) — these five doubles are declared nowhere.

Why it fails now

clang 16 promoted -Wimplicit-function-declaration from a warning to a default error (the C99 non-conformance cleanup; GCC 14 followed). So a default cargo buildsimd is on by default — hard-fails on any clang ≥16 while parsing those headers:

xmmintrin.h:600:52: error: call to undeclared function 'lrint'; ISO C99 and later do not support implicit function declarations
emmintrin.h:388:52: error: call to undeclared function 'fabs'; ...
xmmintrin.h:629:17: error: call to undeclared function 'llrintf'; ...

It's a frontend diagnostic, not a link failure — the helpers are mostly unused and would be dropped at link, but the parse error fires regardless. It stays hidden on older clang (implicit-decl still a warning) or a toolchain whose own headers declare these ahead of the shim. Reproduces cleanly under zig cc (clang 18) with a strict -ffreestanding include layout where nothing leaks the decls.

The fix

Add static inline definitions to the shim math.h. They lower to native wasm ops (f64.abs, f64.nearest + trunc conversions) — no libcall, and no Rust-side libm export needed, so the fix is self-contained in the header. Zero behavior change for toolchains that already build: clang lowers fabs/lrint to the same native ops today; this only makes the declarations always visible.

Alternatives considered

Bare extern declarations (matching the existing float-decl style) + exporting the doubles from stdb.rs like sinf/etc. Works too, but needs a Rust export and a libcall; the inline-builtin form avoids both. Happy to switch to whichever you prefer for consistency.

Verification (wasm32-unknown-unknown)

  • Baseline (simd default, clang 18 via zig cc): fails with the errors above.
  • With this patch: cargo build -p box3d-sys --target wasm32-unknown-unknown compiles clean.

Repro note (zig cc only)

If reproducing with zig cc, also rewrite -isystem <dir>-I <dir> for the shim dirs: zig prepends its bundled x86 intrinsic headers ahead of caller -isystem dirs and would otherwise shadow the compat shims with real x86 SSE2. Not relevant to the fix itself — noted in case it helps anyone verifying.

The bundled wasm-sse2 compat headers (emscripten's SSE2->wasm128 shims,
under shims/include/wasm-sse2/) reference fabs/lrint/lrintf/llrint/llrintf
in their inline conversion helpers, but the freestanding shim math.h never
declares them and stdb.rs exports only the float libm functions.

clang 16 promoted -Wimplicit-function-declaration to a default error, so on
any clang >= 16 a default (simd) build fails while parsing those headers:

  xmmintrin.h:600: error: call to undeclared function 'lrint'
  emmintrin.h:388: error: call to undeclared function 'fabs'

Older clang (implicit decl = warning) or a toolchain whose own headers
declare these hides the gap. It reproduces cleanly under zig cc (clang 18)
in a strict -ffreestanding include setup where nothing leaks the decls.

Add static inline definitions that lower to native wasm ops (f64.abs,
f64.nearest + trunc conversions) — no libcall and no Rust-side libm export
needed, so the fix is self-contained in the shim regardless of whether any
path actually references them.
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