[teo1747]

A wrong-code bug on main, found by the PR fuzz job on #200 (seed 1038932645: x86-64 at -O2, -O3 and -Os; every other board right). It must land before 0.1.0 is tagged.

The bug. The x86-64 backend keeps a cache of which value rax holds. addr_reg, which puts a stack-held address in rcx for a float load, did it as mov slot,%rax; mov %rax,%rcx without telling the cache. The next instruction that wanted the value the cache still named used rax as it was:

lea    -0x30(%rbp),%rax      # &la, cached in rax
mov    %rax,-0x68(%rbp)
mov    -0x38(%rbp),%rax      # addr_reg: the double's base, through rax
mov    %rax,%rcx
movsd  0x8(%rcx),%xmm7
movswl 0x2(%rax),%eax        # la[1]... read from the double's base

The fix. The address is loaded straight from its slot into rcx; rax is untouched. The other places that write rax directly all run after a cache reset (calls, memcpy, memzero, va_start, 128-bit and x87 arithmetic) or in the prologue; this was the only one in the middle of an operation that trusts the cache.

Test. tests/exec/x86-addr-reg-cache.c is the fuzz program, reduced. The reduction was checked against UBSan, ASan and clang's return-type and uninitialised-variable warnings: a first reduction had dropped return statements, and the guard rejected it. Against the old compiler it fails at -O2 and -Os; with the fix it passes at every level. Hand-written versions did not trigger it: whether it happens depends on the allocator spilling both the pointer and the array's address.

Checked.

• make check: 442/442.
• The 150 seeds of embar: Mach-O archives as Apple's ar writes them (fixes the 0.1.0 macOS release build) #200's fuzz job on x86-64, M4, M0, RV32 and RV64 at -O2 -O3 -Os: all pass.
• 300 more x86-64 seeds at -O1 -O2 -O3 -Os: all pass.
• The x86-64 goldens exec-Os, regalloc-O2, optimizer, big-functions and agrees-with-gcc: pass.