mingw 32-bit: realign the stack in our callbacks

[tonycoz]

A default 32-bit mingw build assumes the stack is 16 byte aligned, which appears to be a problem with gcc.

With quadmath enabled, libgcc includes instructions that require 16-byte alignment and access relative to the stack pointer, and when the stack isn't aligned, results in a crash.

To prevent that add the force_align_arg_pointer attribute to our callbacks for 32-bit gcc on Windows.

Fixes #21313

[sisyphus]

Fixes #21313

Indeed - nice work.
It works fine for me with both mcf-threads and posix-threads builds, irrespective of gcc vendor.
Thanks @tonycoz, @xenu,
I look forward to seeing this PR pushed in time for the 5.39.2 release.

There's a comment in the patch (in perl.h) that it might pose a problem for XS code that performs a callback, so I built a couple of modules of mine that do that, and found no issue.
The opening sentence of that comment seems a bit clumsy. IIUC it would be better rewritten as:
When generating code for 32-bit windows gcc assumes the stack is 16 byte aligned, though the system doesn't guarantee that.

Cheers,
Rob

[khwilliamson]

Though I'm not an expert on this

[leonerd]

Seems reasonable.

Though I agree with your comment - there may still be XS modules invoking callbacks and the like which will want this adding. If that becomes too many to manage we may have to think about other options.

[leonerd]

Tiniest of nits: There's a double space in this line of comment

[tonycoz]

There's a comment in the patch (in perl.h) that it might pose a problem for XS code that performs a callback, so I built a couple of modules of mine that do that, and found no issue.

It's only going to be a problem when the callback is called through something that doesn't preserve the 16-byte alignment (gcc produced code does), and then the callback does something that requires the 16 byte alignment, like comparing a __float128 as my crashing example does, or calling into perl codes that does that. Specifically SSE code could be a problem too, or code built with a sufficiently high -march=... which might be autovectorized.

I could see callback via qsort being a problem, or many Win32 API functions, but in most cases the callback is going to be fairly trivial and won't execute an of the SSE ops that cause the crash.