acaf0152dac1ef189003a32c29304373a1961589
Both stages materialise a float literal as a 64-bit double in X0 (MOVQ bits -> MOVSD), ignoring the node type. For an f32-typed literal the downstream MOVSS reads the low 4 bytes of that double — garbage (0.0f for clean values, which is why 0.0 survived the bug and 951's f32 rows, which only assert NaN ordering, never caught it). Append CVTSD2SS X0,X0 at both literal sites (N_FLOATLIT + the float-typed N_INTLIT arm) when the node is f32-typed, so the value reaches X0 as a true single. Mirror in cgenexpr.ww (rule-10) and regen the w6c/wwdump combined.ww embeds. Covers literals carrying an explicit f32 type (the `f32` suffix and the no-decimal `8f32` N_INTLIT arm). An un-suffixed literal in an f32 context (`let x: f32 = 1.0`) stays ty_untyped_float through the checker, so its node is never f32-typed and this branch can't fire — that needs fold-2 (checker untyped-float -> f32 lowering, both checkers). 964_f32lit_run: cstage run + cs==ww byte-id probe over concrete f32 values (suffixed), the hole 951 leaves open.
Description
No description provided
Languages
C
89.4%
Python
7.2%
Makefile
2.3%
Shell
0.8%
Assembly
0.3%