https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111107
--- Comment #35 from Gabriel Ivăncescu <gabrielopcode at gmail dot com> --- (In reply to LIU Hao from comment #34) > > My experience is that _sometimes_ (how often?) GCC assumes the stack is > aligned. Yes, in theory it shouldn't, but in practice that's not the case. > Maybe we can do that on master, but it will require a lot of testing. > > See also https://bugs.winehq.org/show_bug.cgi?id=55007 This most likely stems from the fact the preferred stack alignment is 16 bytes, which is why it assumes wrong if that's not the case from an unknown caller. For example if preferred stack alignment is 16 bytes and it calls a non-exported function for which GCC sees all callers, it could conceivably assume it's 16-byte aligned upon entry (I've no idea if it does this optimization though). But that shouldn't apply to callers of unknown origin, including potentially MSVC code. Otherwise, it's a serious bug that ought to be fixed separately and IMO not worked around in this patch (if it's even still an issue, probably not). Just imagine what happens if the caller is MSVC code that only uses 4 byte alignment, which is basically rest of the Windows world outside of MinGW. Then GCC doesn't realign because of some supposed bug and it crashes. Wine is a pretty big user of such interoperability since it has to always work with any Windows code in the wild, not just those built by GCC. We haven't had issues with setting both incoming and preferred-stack-boundary to 2 (4 bytes) on the PE i386 target. Well, unless it was a legitimate GCC bug that had to be fixed anyway.
