32-bit Windows: reinterpret<uint64>(@@fn) reads garbage in the high 32 bits - tests/language/func_addr.das fails on the windows-32 Release lane

[borisbat]

What fails. The per-PR lane build (windows, 32, Release, none), interpreter sweep, one file: tests/language/func_addr.das, the block "a function address is a non-null uint64 handle in every store position". Every store position of reinterpret<uint64>(@@fa_add) reads the right address in the low 32 bits and garbage in the high 32, the same garbage in every position, while the same value passed through a parameter (fa_handle_of(@@fa_add)) reads clean:

func_addr.das:60: assignment to a local        expected: 0x12bc9550   got: 0xcfbfb012bc9550
func_addr.das:61: declaration with initializer expected: 0x12bc9550   got: 0xcfbfb012bc9550
func_addr.das:62: fixed-array element store    expected: 0x12bc9550   got: 0xcfbfb012bc9550
func_addr.das:63: struct field assignment      expected: 0x12bc9550   got: 0xcfbfb012bc9550
func_addr.das:64: struct literal field         expected: 0x12bc9550   got: 0xcfbfb012bc9550
func_addr.das:65: arithmetic operand           expected: 0x12bc9550   got: 0xcfbfb012bc9550
func_addr.das:66: cast to void?                expected: 0x12bc9550   got: 0xcfbfb012bc9550
func_addr.das:67: cast to int64                expected: 314348880    got: 58476083128603984
func_addr.das:70: the direct spelling inside a return   expected: 0x12bc9550   got: 0xcfbfb012bc9550
13300 tests, 13282 passed, 1 failed, 0 errors, 17 skipped

Run: https://github.com/GaijinEntertainment/daScript/actions/runs/34309492023/job/102333115328 (PR #3978, tip bb0b5e2).

Where it comes from. The test and the typed slots it exercises landed in 3825401 (PR #3974, fixes #3970): SimNode_FuncConstValue / SimNode_FuncConstValueMnh gained evalPtr / evalInt64 / evalUInt64 as cast<CTYPE>::to(eval(context)), where eval returns cast<SimFunction *>::from(fun). On 32-bit that chain reads clean as far as I can follow it: cast<TT *>::from is v_ldu_ptr, which on 32-bit MSVC is the out-of-line v_seti_x((int32_t)a) in src/misc/hal.cpp (_mm_cvtsi32_si128, upper lanes zero), and cast<uint64_t>::to is v_extract_xi64 = v.m128i_i64[0]. So the high half enters somewhere else on the 4-byte-pointer-into-8-byte-slot path that a 64-bit build never takes, and the identical 0xcfbfb0.. in every position says it is one uninitialized read per evaluation, not per store.

Nondeterministic. PR #3974's own windows-32 lane passed the same test (run 34282514548). PR #3978 changes nothing under src/, include/ or the interpreter (its diff is dasSpirv, dasLLAMA, tests/spirv, skills and docs), and the test fails on its tip; a rerun of the failed lane was issued to tell flaky from deterministic on the merged tree.

Reproduce. A 32-bit MSVC Release build, then daslang dastest/dastest.das -- --test tests/language/func_addr.das.

[borisbat]

Re-ran the lane once on the same tip (job 102338987181): same file, same nine positions fail, with a different high half this time - expected 0x1267e950, got 0x6fbd401267e950 (the first run read 0xcfbfb012bc9550 against 0x12bc9550). So the failure is deterministic on the merged tree and the high 32 bits are whatever sits in memory: an uninitialized read on the 32-bit path, not a stale value.