Now that emit_llvm.zig bridges the struct<->[2 x i64] ABI mismatch
(previous commit), the 9..16-byte integer-only shapes round-trip
cleanly. Extended `examples/ffi-02-small-struct.sx` to cover all
four aggregate ABI slots in one place:
Vec2 — 8 B, two f32 (register pair, float)
Vec4f — 16 B, four f32 (HFA — homogeneous float aggregate)
Pair64 — 16 B, two s64 (9..16 B int — [2 x i64] coercion slot)
Quad32 — 16 B, four s32 (same slot as Pair64)
Vendor helpers (`vendors/ffi_structs/{ffi_structs.h,ffi_structs.c}`)
grow `ffi_pair64_*` + `ffi_quad32_*` companions. Snapshot updated
to capture the full output. 89/89 regression tests pass.
`examples/101-ffi-medium-struct.sx` keeps a minimal focused repro
of the Pair64 case so the issue's emergence-and-fix history stays
greppable.
Resolves issue-0036 (LLVM verifier failure on 16-byte integer-only
struct by value through #foreign). The mismatch:
Call parameter type does not match function signature!
%load = load { i64, i64 }, ptr %alloca, align 8
[2 x i64] %call = call [2 x i64] @fn({ i64, i64 } %load)
`abiCoerceParamType` had already chosen `[2 x i64]` for 9..16-byte
non-HFA structs (the AAPCS64 / SysV AMD64 register-pair ABI slot for
that size class) on the foreign-decl side, but `coerceArg` only knew
how to bridge struct<->integer (the ≤8 B case) — not struct<->array.
LLVM's verifier rejects type-mismatched call args, so the call site
never landed.
Added the symmetric branches in coerceArg:
- Struct -> Array : alloca <array>; store <struct>; load <array>
- Array -> Struct : alloca <array>; store <array>; load <struct>
Both use the LLVM opaque-pointer memory-bitcast pattern already in
place for the integer case. They're paired with the existing
i64 <-> small-struct bridge so all four (≤8 B int, 9..16 B int,
16 B HFA, >16 B byval) ABI slots round-trip cleanly through
emit_llvm now.
File mechanics: promotes the issue-0036 repro to a focused feature
example per CLAUDE.md's issue-resolution workflow:
examples/issue-0036.sx -> examples/101-ffi-medium-struct.sx
tests/expected/issue-0036.{txt,exit} -> tests/expected/101-ffi-medium-struct.{txt,exit}
vendors/issue_0036/issue_0036.c -> vendors/ffi_medium_struct/ffi_medium_struct.c
Snapshot updated to the passing output. 89/89 regression tests pass;
chess Android build still clean.
Surfaced while writing the ffi-02-small-struct.sx baseline. The sx
#foreign decl lowers `{ s64, s64 }` (and other 16-byte integer-only
shapes like `{ s32, s32, s32, s32 }`) to `[2 x i64]` for the small-
struct register-pair ABI on AAPCS64 / SysV AMD64, but the call site
loads the struct as `{ i64, i64 }`. The two types must agree for the
LLVM verifier to accept the call:
Call parameter type does not match function signature!
%load = load { i64, i64 }, ptr %alloca, align 8
[2 x i64] %call = call [2 x i64] @issue0036_swap({ i64, i64 } %load)
Float-only 16-byte aggregates (e.g. Vec4f) work because they route
through the HFA path which keeps the struct representation. See
examples/ffi-02-small-struct.sx for the working cases.
Phase 1's #foreign lowering rework is the natural place to unify
these representations; check there before fixing inline.
88/88 regression tests pass (+ffi-02-small-struct).
vendors/ffi_structs/ defines:
Vec2 — 8 B, two f32 — register-pair (float) ABI
Vec4f — 16 B, four f32 — homogeneous float aggregate (HFA) on AAPCS64
Both pass cleanly today: the sx-side struct declarations match the C
ABI for these float-only shapes, and the call-site / foreign-decl
type representations agree.
`#source` only (no `#include`) — c_import's type mapping rewrites
struct-typed params/returns to *void, which would link but pass
through the wrong ABI silently. The hand-written #foreign decls keep
sx's struct types end to end.
16-byte integer-only shapes (`{s64, s64}`, `{s32, s32, s32, s32}`)
discovered to trip the LLVM verifier (`[2 x i64]` vs `{ i64, i64 }`
mismatch between foreign decl and call site). Excluded from this
baseline; filed separately in the next commit as issue-0036.
87/87 regression tests pass (was 86; +ffi-01-primitives).
vendors/ffi_primitives/{.h,.c} exposes a trivial identity roundtrip
per primitive C type — int/uint/short/ushort/long long/unsigned long
long/signed char/unsigned char/float/double/void* — plus two-arg
add helpers (int + double) for multi-arg ABI exercise. The sx-side
example imports the .h via `#import c { #include / #source }` and
prints each result; the snapshot in tests/expected pins today's
parameter + return ABI so Phase 1's #objc_call / #jni_call lowering
work can't silently regress primitive marshalling.
Two findings logged in current/CHECKPOINT-FFI.md's Known issues
section (current behavior, not new bugs): (1) c_import.zig maps
`signed char` -> `u8` not `s8`, and (2) sx integer-literal parser
rejects values >= 2^63 as overflow even when the receiver is u64.
Both worked around in this test without blocking the baseline.
