Hojun-Cho
b79f005489
An over-cap tuple mixing a scalar with slices/str (e.g. (int,[]u8,str),
56B) laid out differently in the two stages — gate-blind, since no
bootstrap path returns such a tuple. Two silent cs!=ww bugs, one per
ABI side:
- callee SEND (cstage cgen.c N_RETURN over-cap-tuple arm): foff
advanced by the LITERAL expression's type size. A bare int literal
element is stamped TY_UNTYPED_INT (size 0), so `e->type->size`
added 0 for a leading scalar — the next element clobbered it at
offset 0 and every trailing element packed 8 bytes low. wwstage
already sized from the return-type tuple (c.fnret.list), so the
callee frames diverged. Fix: size foff from cg_ret_type's tuple
params (rule-13 type table), aligning cstage to wwstage and to the
t.N reader's f->offset.
- caller RECEIVE (wwstage cgenstmt.ww cglet N_TTUPLE arm): the
in-cap register tuple-receive branch had no capacity gate, so a
56B over-cap tuple was received via AX/DX/CX/R8 (+ R8 fill)
instead of from the sret dest the callee wrote. cstage gates the
twin branch on `sz == 16 || sz == 32` and falls over-cap tuples
through to the sret receive. Fix: add the same size gate to
wwstage, aligning it to cstage.
Both stages now emit byte-identical asm and the value round-trips.
Regen w6c + wwdump combined.ww (cgenstmt embeds in both).
New 940_mixed_scalar_tuple_sret_run: leading/trailing/middle scalar
shapes, annotated + inferred let, each self-asserting every element
(scalar direct, slice/str via len) — both drivers exit 0 + cs==ww
byte-id (12/12).