Of course this shouldn't apply to Win32 PE DLLs. GCC seems a bit stubborn about that, just because Linux enforced 16-byte alignment at some point on their ABI, it's not the same on Windows.
I don't even understand why the GCC devs have so many workarounds for this. Why does -msse2 or SSE even matter at all? The simple fact is that incoming alignment is only guaranteed to be 4 bytes on some platforms, such as i686-MinGW (32-bit Windows PE), and GCC should realign the stack *if* it needs more alignment than that, SSE or not. **Any** variable requiring more alignment should enforce that.
To be clear, I'm not trying to defend GCC's historic decisions here; I think that maintaining compatibility with the de-facto MSVC ABI would have been the right choice. I do not think that fixing the problem partially like that was a very well though out idea. Happily, there may be motion to rectify that now.
BTW here's an example of incoming=2 and preferred=4: it will assume incoming stack (if function is not static, that is, since it doesn't know the caller) is 4 byte aligned, and so it will realign it since it "prefers" 16 bytes, whether it actually needs 16 byte alignment or not.
incoming=2 and preferred=2 won't realign unless a variable explicitly requires more than 4 bytes alignment, so it's the most ideal, and how MSVC behaves when building 32-bit.
Ah, I see, that makes sense. And -mpreferred-stack-boundary implies a maximum for -mincoming-stack-boundary.
I will assert the naming is confusing; you'd expect "preferred" to be optional in some respect.