https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111107
--- Comment #10 from Gabriel Ivăncescu <gabrielopcode at gmail dot com> --- (In reply to Alexander Monakov from comment #9) > -mpreferred-stack-boundary=n means that functions consume stack in > increments of 2**n. This is sufficient to ensure that once stack is aligned > to that boundary, it will keep it without the need for dynamic realignment. > > -mincoming-stack-boundary specifies the guaranteed alignment on entry. If > the function needs to place local variables with greater alignment > requirement on the stack, it has perform dynamic realignment. Yeah, but on 32-bit x86 Windows ABI, the stack is only guaranteed to be aligned to 4 bytes (mincoming-stack-boundary=2). We don't control the callers, and apps compiled with MSVC (i.e. the majority of them, including Windows' own libraries) only adhere to this alignment, nothing more than that. Therefore -mincoming-stack-boundary=2 should be the default on MinGW for this target. In general, setting -mpreferred-stack-boundary=2 is also preferable because the vast majority of functions do *not* use SSE or AVX or whatever. If you set -mpreferred-stack-boundary=4 it will *always* align the stack on entry, and that's simply too much overhead. It's better only for functions that actually need it to do it. The point is, -mpreferred-stack-boundary=2 (and consequently -mincoming-stack-boundary=2) is the default on MSVC and Windows 32-bit x86 ABI, and that's for a reason. MinGW should follow that. By default, at least. I've compiled Wine with those options for years now without trouble.
