mulx_lowering failed twice on the x86_64 macOS relinker job, which runs emulated on an arm runner
(d68b36002d, run 41582706998, and 66387a10ee, run 41601236599), and passed in nine other runs of the
same code. The failure only said "MULX changed arithmetic flags". It now also prints the input and
output flag bits, the bits that differ, and the operand shape, so the next failure shows whether it
is the auxiliary or parity flag or one of the flags the lowering actually has to preserve.
An island or relocation window could start in the int3 or nop padding after a jump or return and run into the next function. A function that only a pointer reaches, such as a virtual method, is not a known branch target, so its first bytes became the middle of a jump to a stub. An instruction that follows a jump, a return, a trap or padding after one of them can now only start a window. An int3 inside a window does not count as such an instruction, so a window that lies entirely in int3 padding is still used, as before; nop padding stays excluded, since a function built with -fpatchable-function-entry can begin with a nop.
masked_store_lowering failed twice under Rosetta on GitHub's macOS x86_64
runner (runs 40216485859 and 40438653738) with only "Masked store stub
changed the flags", while the stored bytes, faults, vector and general
registers, red zone and RSP all matched. The message now names the form,
width, addressing mode, offset, mask pattern, fault count and the flags
before and after, so the next occurrence shows which flags change and
whether the probe faulted.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Operand-size-prefixed (0x66) relative branches are classified as having
no branch target, so the AdjustedDelta check never saw them. The
truncated-branch guard only checked whether the branch and its target
move apart, so `66 EB 01 B8 11 22 33 44 C3` rewritten at offset 3 was
accepted and the branch landed in the middle of the new bytes.
Reject a truncated branch whose target is inside the cut, and run that
check for same-length rewrites too, matching the rel8/rel32 path.
In a leaf without a frame pointer, --frame-red-zone lowers RSP after
the prologue and adds the shift to every RSP operand in the body,
assuming RSP does not move between the prologue and the exits. It
refused explicit RSP arithmetic but not opcode-encoded pushes and pops,
so after "push rax" in the body the read of the pushed slot at [rsp]
became [rsp+0x10], a red-zone slot, and "pushfq; and qword [rsp], -2;
popfq" changed that slot instead of the saved flags. Such a leaf now
keeps its red zone and is reported as "push or pop inside the body":
push and pop of a register, push imm, push r/m, pop r/m, pushf, popf
and push or pop of fs or gs outside the exits. The pops of an exit
still frame, and leaves with a frame pointer, whose RSP operands are
already refused, still frame when they push and pop.
Dean Galvin