#30 (82be8b9) shipped the f64 variant-widen MOVSD path, but cg_widen_tagged_store's float-arm gate `fld_isfloat` only accepted declared f64/f32 — not TY_UNTYPED_FLOAT. cunop on TK_MINUS over an N_FLOATLIT returns the operand's type (ty_untyped_float), and cbinop on two untyped-floats returns ty_untyped_float too. So `let a: (i64 | f64) = -2.5;` and `(2.5 + 1.0)` fell through to the scalar fallback and stored AX residue at payload+8 (tag still set correctly, payload = 0). Wwstage post-#30 was already correct via exprfloatkind's AST walk. Extend fld_isfloat to accept TY_UNTYPED_FLOAT (defaults to f64, no TY_UNTYPED_F32 exists). Acceptance set now matches cg_isfloat exactly. All 15 other fld_isfloat call sites pass declared field / element / pointee types that never carry TY_UNTYPED_* post-check — no over-trigger. Test 715 grows from 7 → 10 rows: unary_neg_floatlit_direct (`-2.5`), unary_neg_floatlit_paren (`-(2.5)`), binop_floatlit_sum (`2.5+1.0`). All pin payload bits via hex-u64 punning through *u8 — direct/paren land 0xC004000000000000 (sign=1, exp=0x400, mant=0x4000000000000); sum lands 0x400C000000000000 (3.5). Hex literal use is documented inline pointing at #41 (orthogonal comparison-ladder bug surfaced during test development; decimal-u64 RHS of != miscompiles). After this lands, lib/fmt/fmttest.ww's 3 routed-around rows (cited at7f320d3) can drop the `let nv: f64 = -2.5;` indirection and use the direct literal — sibling cleanup.
242 KiB
242 KiB