This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: g++ 3.4.0 cygwin, codegen SSE & alignement issues


At 08:51 AM 4/28/2004, Dave Korn wrote:

> -----Original Message-----
> From: cygwin-owner On Behalf Of tbp
> Sent: 28 April 2004 16:16

[  Now x-posted to gcc list, since it's seemingly a gcc issue rather than a
cygwin environment issue.  You might also care to refer to the current
discussion on the gcc-patches mailing list under the thread

"Re: [Bug target/15106] Vector varargs failure for AltiVec on ppc32 linux"

which is discussing the same problem arising on ppc targets. ]


> > It's an ABI incompatiblity issue, GCC expects a 16-byte > aligned stack, > > but the Windows ABI, to the extent one actually exists, only assumes > > a 4-byte aligned stack (and even that's not a strict requirement). > Is there an official or semi official way to fix it or do i have to > insert something like "mov esp, eax; and 0x15, eax; sub eax, > esp" where > it helps?

  I'd recommend doing that in the startup code in gcc's crt0.s myself.  The
real question is, is the compiler generating code that guarantees the stack
stays aligned, so you can do that just once at startup?  It certainly ought
to.

> I understand -mfpmath=sse is flagged as experimental. What i
> don't get
> is why the compiler emits totally bogus code when using default
> switches: -O3 -march=k8 -> boom. -O3 -march=pentium4 -> boom.

  The division of responsibility between OS, CRT/startup and compiler leaves
it unclear as to who is supposed to ensure the alignment of the stack.  IMO,
it's a compiler's problem to see to it that if the stack starts off aligned
it remains that way, by always generating stack frames that are a multiple
of the alignment requirement, and it's the CRT/startup code that is
responsible for mediating between what the compiled code requires and what
the underlying OS/arch provides for stack pointer alignment at startup.  Of
course, that's IMO, and my opinion is hardly definitive.


As Dave said, this is more of a gcc than a cygwin issue, provided that cygwin doesn't defeat one of the functions of binutils or gcc (as it did in the past). gcc made a decision, which is different from commercial compilers, that stack alignment requires each function to be compiled with -mpreferred-stack-alignment=4, so that it passes an aligned stack to the callee. binutils has to be built with maximum alignment set to at least 4 (as cygwin has done for some months now).


stack-alignment=4 is a default for gcc, except when -Os is specified. If you use -Os, and any called function uses SSE, you must over-ride the stack alignment set by -Os. gcc did this because the stack alignment caused some applications (which don't use SSE) to fail with stack overflow. I suspect this could happen in cygwin.

Because of the different division of responsibilities, if a function built by gcc is called by a function built by a commercial compiler (or by gcc -Os), the stack has a 75% probability of being mis-aligned. It may be possible to overcome this by having a wrapper function between, which is built by gcc with alignment specified, but does not use SSE.

Presumably, there is a performance advantage to gcc of assuming that the caller passes an aligned stack, but not enough to persuade commercial compilers to adopt a compatible scheme.


Tim Prince



-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]