https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111107
--- Comment #33 from Gabriel Ivăncescu <gabrielopcode at gmail dot com> --- (In reply to LIU Hao from comment #31) > (In reply to Gabriel Ivăncescu from comment #30) > > Why would it not be safe? For MinGW specifically, what's not safe about it? > > The entire Windows stack assumes only 4-byte alignment for i386, because > > that's what MSVC provides. So interoperability with MSVC code (including > > Windows DLLs or 3rd party libraries) means that anything that requires > > stricter alignment *MUST* realign the stack, or else it would break. > > > > Therefore it should be completely safe for Windows i386 target. > > There's code that expects `__attribute__((__force_align_arg_pointer__))` to > align the stack to 16-byte boundaries. > > https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682180.html Shouldn't using SSE automatically re-align it to 16, seeing as the alignment requirement is stricter? I don't see how __force_align_arg_pointer__ is useful at all for Windows i386 target, nor why it should have any effect. The documented usage of it is "This supports mixing legacy codes that run with a 4-byte aligned stack with modern codes that keep a 16-byte stack for SSE compatibility." but there's no such thing as "modern codes that keep a 16-byte stack" for Windows i386 target. It used to be needed in old Wine versions, before we built builtins as PE, because they were unix shared objects, and obviously the target then uses 16-byte aligned stack, so it was necessary. But this patch shouldn't touch that target, so even building an old Wine version shouldn't break as it's not Windows i386 in the first place.
