C passes a va_list argument by value. The bindings took ^va_list, which
only matches x86-64 System V, where va_list is an array that decays to
a pointer. On Darwin, Windows and the other targets va_list is a
pointer or a struct, so vsnprintf and friends received the address of
the list instead of the list and printed or scanned garbage.
The foreign declarations now use the platform's form, and the public
procedures keep taking ^va_list so callers stay portable.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Calling these failed to compile: `_mm256_round_pd` passed a u8 where
the intrinsic takes a u32, `_mm256_blend_pd` misspelt its parameter,
`_mm256_dp_ps` took its mask as an i8, `_mm_permute_ps/pd` used
SSE/SSE2 helpers without enabling them, and `_mm256_permute2f128_pd`
did not return its result.
`_mm_cvtsd_ss` passed two `__m128d` to `llvm.x86.sse2.cvtsd2ss`,
which takes `(<4 x float>, <2 x double>)`, so LLVM failed with
"Intrinsic has incorrect argument type". `_mm_cvtss_sd` used
`llvm.x86.sse2.cvtss2sd`, which LLVM no longer has. Both wrappers
also took the wrong operand types; use Intel's (a: __m128, b: __m128d)
and (a: __m128d, b: __m128), and express `_mm_cvtss_sd` as a lane
conversion as clang does.
`_mm_prefetch` called `llvm.prefetch` without its pointer mangling and
`__rdtscp` declared `llvm.x86.rdtscp` as taking a pointer when it
returns `{i64, i32}`; both were rejected by LLVM too.
LLVM has dropped many x86 intrinsics in favour of generic IR, and
auto-upgrades them only when reading bitcode. Odin declares them
directly, so the calls became undefined external symbols and failed
to link, e.g. `undefined reference to llvm.x86.sse41.pmaxsb`.
Express the affected wrappers the way clang's headers now do: scalar
lane ops, simd.min/max/abs/sqrt, shuffles for the immediate blends,
masked or narrowed multiplies, conversions and an unaligned store.
`_addcarryx_*` now use `llvm.x86.addcarry.*`, as clang does.
`_mm_sqrt_ss` took an unused second argument; it now takes one, as
in Intel's definition. It could not have been used before.
init left the round start untouched. A context that skipped zeroing
with `= ---`, or one reused after TurboSHAKE, kept a stale value, so
SHA-3 and SHAKE ran too few rounds and returned wrong hashes silently.
bplu4t2f