[Bug target/126741] x86_64-w64-mingw32: 512-bit by-value arguments and return values are stored to caller stack temporaries with aligned vmovapd, but the temporaries are only 16-byte aligned — runtime crash (0xC000000 5)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126741

--- Comment #3 from Gary Wolfman <gdwolfman at icloud dot com> ---
Upon further testing, the defect is not specific to 512-bit vectors: the
identical wrong-code pattern is emitted for 256-bit by-value arguments and
return values under plain -mavx2, which widens the affected audience from
-mavx512* users to any Win64 MinGW code that passes a __m256/__m256d (or a
struct wrapping one) by value across a non-inlined call boundary.

Reproducer attached (repro-avx2.cpp, 52 lines, freestanding — same structure as
the original, with the alloca walk covering the two ABI-legal 16-byte residues
mod 32). Output on Ryzen 7 7445HS / Windows 11: faults with 0xC0000005 at the
first shift; expected is both shifts printing "ok (28)", which is what a
clang-cl 22.x build of the same file does. As with the 512-bit case, -O0
reproduces and -mstackrealign changes nothing.

Disassembly (driver, g++ -O2 -mavx2): prologue is a plain sub $0x88,%rsp; the
argument temporaries at 0x20/0x40(%rsp) are written with aligned vmovapd and
the return slot at 0x60(%rsp) read the same way, while the data-array loads in
the same function are correctly unaligned vmovupd. The slots are 32-byte
aligned only when entry rsp ≡ 24 (mod 32) — one of the two ABI-legal residues —
and there is no realignment anywhere in the function.

Verified on the WinLibs r4 build of GCC 16.1.0 (original report was against
r2). The summary line's "512-bit" could be generalized to "256- and 512-bit".
Credit: the AVX2 reduction was contributed by an independent tester of corvus
and verified on the machine the original report was filed from.