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.