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.
