Delete/test whether gcc-avx-misaligned.patch and gcc-stdcall-align.patch are needed for GCC 16

[Peter0x44]

Even though GCC 16 isn't due until April, just filing this as a reminder to test whether those two patches are still necessary when updating. Before I forget about it.

Supposedly, the issues were fixed upstream by these two commits:
https://gcc.gnu.org/cgit/gcc/commit/?id=dea7b9a78b11b5ca0c85b971521144ba07a66aca
https://gcc.gnu.org/cgit/gcc/commit/?id=ee7c0a5b70dc316477f45abc0f09dd2af9abe5cb

[skeeto]

Thanks for the heads up! A proper upstream fix is always better than my hacks! Though I don't understand the meaning first commit: I've always enabled SSE2 in w64dk's x86-32 builds, and yet it still has trouble with stack alignment. Or is the commit message referring to some other change not yet in a release? Unless I'm misunderstanding, the AVX patch is still required because these GCC changes only apply to x86-32, and so GCC is still unable to align the stack for AVX. As I understand it, it's some complication with the ABI and isn't easy to solve.

[Peter0x44]

I am also a little bit unsure. Allegedly, it fixes avx512f as well:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273
(but for i686-w64-mingw32???)

[Peter0x44]

@lhmouse could clarify, I guess.

[Peter0x44]

OK, I asked, no, unfortunately it doesn't cover x86_64. If he doesn't get around to writing a comment here, I'll summarize what he told me myself.

[lhmouse]

@Peter0x44

Even though GCC 16 isn't due until April, just filing this as a reminder to test whether those two patches are still necessary when updating. Before I forget about it.

Supposedly, the issues were fixed upstream by these two commits: https://gcc.gnu.org/cgit/gcc/commit/?id=dea7b9a78b11b5ca0c85b971521144ba07a66aca https://gcc.gnu.org/cgit/gcc/commit/?id=ee7c0a5b70dc316477f45abc0f09dd2af9abe5cb

Before this change (the second one overwrites the first, so there's only one change):

• GCC assumed that ESP was aligned to 16-byte boundaries (preferred stack alignment = 128 bits).
• Stack realignment did not happen when SSE was not enabled. (This is a tricky circumstance where stack alignment is 16 bytes but it isn't enforced at all, for example in callbacks from Microsoft code the stack is almost never aligned.)
• When SSE was enabled, GCC took the assumption about 16-byte alignment, and did not re-align ESP. So something like movaps [esp+16], xmm6 could cause a fault.

After this change:

• GCC assumes that ESP is aligned to 4-byte boundaries, same as MSVC.
• When SSE is enabled and necessary, a large alignment value is requested, so GCC realigns ESP to a 16-byte boundary in the prologue.

This change eliminates the (incorrect) requirement of __attribute__((__force_align_arg_pointer__)) on callback functions, such as window procedures, FLS callbacks, and thread entry points.

Only x86-32 supports realignment of ESP in the prologue. x86-64 requires SEH unwinding information which can't encode that.

[Peter0x44]

Right. So probably, gcc-stdcall-align.patch seems like it can be deleted, but the gcc-avx-misaligned.patch remains needed. (except for 32 bits?)

[skeeto]

Thanks for the information, @lhmouse! Very informative, and I appreciate it.

but the gcc-avx-misaligned.patch remains needed

That's my understanding as well. It's also the less hacky of the two.