PATCH: Don't allocate space for SSE reg in reg save area if SSE is disabled

[Linus Torvalds]

On Fri, 29 Aug 2008, Richard Guenther wrote:
> 
> In addition I think you need to say that -mno-sse changes the ABI and
> calling vaargs functions across CUs compiled with different -mno-sse
> setting is not supported?  If this is true then I think a new option
> controlling this should be added and -mno-sse shouldn't be overloaded
> with this.

I don't think the ABI really changes for va_arg any differently than it 
does for anything else. With -mno-sse, gcc will obviously create code for 
va_start() that simply doesn't save the SSE registers anywhere. That is 
not new to this situation, btw, that's always been true.

So if you have a caller that _tries_ to use SSE registers for that va_list 
(because the caller wasn't called with -mno-sse), then they'll be ignored, 
and if the va_list user then tries to extract them (because just 
va_start() was compiled with -mno-sse and the eventual va_list user was 
not), the end result is random crud because they were never saved.

But neither of those results are new behavior to hjls patch. The code 
generated is all the same for saving the arguments - the only difference 
is that the stack save area is no larger than needed for that saving.

Of course, the fact that gcc no longer even allocates the save area for 
the non-existent SSE registers means that the case that didn't work before 
may work _differently_ - in particular, if you are at the very top of the 
stack when calling it, you could in theory get a page fault when trying to 
access the nonexistent SSE overflow area. But quite frankly, I bet it is 
(a) impossible to trigger (b) a buggy situation to begin with and (c) if 
it triggers, a page fault is probably better than loading random 
uninitialized data _anyway_ from a debugging standpoint.

That all said - mixing code that was compiled with -no-sse and -sse is 
insane anyway. It _is_ a different ABI. But it does happen to work if you 
simply don't use anything that needs it, and that includes mixing vararg 
functions. 

In particular, using -mno-sse will still generate the "%al contains zero" 
for the case of calling varargs functions, so it's all consistent as far 
as the calling convention is concerned _apart_ from the case of somebody 
actually passing FP/SSE arguments.

				Linus