http://bugs.winehq.org/show_bug.cgi?id=22316
--- Comment #15 from Alexandre Julliard julliard@winehq.org 2011-07-12 14:57:30 CDT --- (In reply to comment #14)
the gcc PR mentioned in comment #1 says the Linux ABI is (being updated to say?) 16 bytes. the man page also indicates that 4 byte is legacy and 16 byte is modern. and further, the man page says that it realigns the stack only when needed. so i dont understand why this would be unacceptable to the wine devs as it doesnt affect code output if no SSE code is generated that needs 16byte alignment.
-mstackrealign Realign the stack at entry. On the Intel x86, the -mstackrealign option will generate an alternate prologue and epilogue that realigns the runtime stack if necessary. This supports mixing legacy codes that keep a 4-byte aligned stack with modern codes that keep a 16-byte stack for SSE compatibility. See also the attribute "force_align_arg_pointer", applicable to individual functions.
This always aligns the stack. It's what we use on the Mac, where the ABI truly is 16 bytes. It has a significant performance cost since it has to be done on every entry point.
It can certainly be used by people who want to build Wine with aggressive optimization, though the cost of the constant realignments would probably wipe out any benefits from the extra optimizations. It's not something we want to do by default if it can be avoided.
The real problem however is gcc causing new alignment requirements to sneak into system libraries. That's what breaks compatibility, and the only solution is for gcc to default to backwards-compatible behavior, and require an explicit option for the new ABI. That's what that gcc bug is about.