On Thu Aug 24 20:31:16 2023 +0000, Zebediah Figura wrote:
Sure, we could, and that'd be another way to solve the problem, but
currently we don't. The fact is that gcc assumes the stack boundary is 16-byte-aligned, period, and that means that not only do we need to force alignment so we don't break the Unix ABI, but we also need to force alignment so that aligned types and variables actually will be aligned.
That's not true, at least not with MinGW. If it were, this would never
have been removed because it would break **every** optimization with anything > 8 bytes (technically, `double` doesn't require alignment), such as vectors. And I compiled that for ages, and it does realign if needed for vectors. If it doesn't, it's a compiler bug. If vector optimizations are used (e.g. -msse2), gcc will manually align the stack for i686-w64-mingw32. This was intentionally done [1]. But that doesn't extend to manually aligned types; those are currently just broken on Wine, as this patch set shows. I originally thought it was a compiler bug too, but the current behaviour *is* intentional, albeit perhaps poorly thought out. See also [2]. [1] https://inbox.sourceware.org/gcc-patches/5969976.Bvae8NF9fS@polaris/ [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111107
What you're essentially saying is that every library built as PE with
MinGW is utterly broken if it uses auto vectorization or types that need 16 byte alignment on the stack without using this attribute? (and most of them don't)
BTW by "every library built as PE" I do not mean Wine's. I mean native
DLLs compiled using MinGW and used on native Windows… It's not a problem if the entire stack is built with mingw, because mingw manually aligns the stack in its crt0, and gcc builds functions that expect and preserve 16-byte alignment. But if you ever mix MSVC and MinGW compiled libraries, yes, you will likely hit a misaligned stack.
I meant if you build a library on MinGW with the intent to have it loadable by any code—on Windows, natively. You don't control the caller's alignment or whoever uses your library. Wouldn't this be a much more widespread issue in such case?
But it looks like -mincoming-stack-boundary=2 is the solution. We could add that somewhere (I don't know anything about configure/winegcc though). I had assumed it *was* the default already, on MinGW i686, but if not it's probably a bug with MinGW rather than GCC as a whole. Since that's the incoming boundary for the Win32 32-bit ABI.
BTW as I can see, -mincoming-stack-boundary means the incoming boundary (i.e. "external" callers to your exported functions), so that's what's important here. You can only assume such stack is 4-byte aligned on 32-bit Windows.
-mpreferred-stack-boundary is how you want to keep the stack in our own functions, i.e. how they "prefer" it. I think it should also be set to 2 to prevent pointless realignments unless necessary. (note that realignment should happen if required by the function, already)