On Fri, Oct 14, 2005 at 02:14:10PM -0700, Kean Johnston wrote:
> How can that possibly ever work? Is the assumption then
> that the only code GCC will ever work with is code that
> GCC compiled? In effect what this implies is that GCC
> is re-defining the ABI.
Yes. You can thank Intel for this.
With the introduction of SSE1, something had to change in order
to satisfy hardware constraints. Intel initially proposed some
scheme that performed dynamic stack alignment in functions that
use SSE1 instructions, and multiple entry points to avoid
redundant realignments.
This turned out to be horribly complex, and in many cases
resulted in yet another register being unavailable to user code,
leaving at times only 4 (!) with pic+alloca+sse.
This kind of solution was unacceptably costly, so we simply
changed the default code generation scheme to maintain proper
stack alignment at all times.
GCC code will interoperate with other compilers if you don't use
the 128-bit vector modes, but if you do, then we *require* that
the stack be maintained aligned.
This has been the status quo since 1998 or 1999, and is unlikely
to change.
> It also means it is impossible
> for GCC to inter-operate with vendor supplied libraries
> like libc.
Yep. Too bad, so sad.
If you've users that actually need to use SSE in callbacks from
bsearch/qsort or the like, then they'll have to write
int __attribute__((noinline))
real_callback(const void *a, const void *b)
{
...
}
int callback(const void *a, const void *b)
{
void * volatile x = __builtin_alloca(1);
return real_callback (a, b);
}
r~
