Re: [PATCH] Clean up builtin expansion logic

[Roger Sayle <roger at eyesopen dot com>]

On Tue, 5 Aug 2003, Zack Weinberg wrote:
> Roger Sayle <roger@eyesopen.com> writes:
>
> > The only exception to this rule seems to be alloca.  Its not too hard
> > to see that although we intercept calls to alloca, we really shouldn't
> > try to implement it using a real call :>.
> >
> > Ok for mainline?
>
> Yes please!

Many thanks.


>         Except, why do we think that alloca is a builtin that has
> a library function, since even if by chance alloca is an exported
> symbol in libc, it can't possibly work to call it?

Its because of the way that GCC intercepts calls to the library function
"alloca" as if they really were library calls.  i.e. the library function
"alloca" has a particular void*(*)(int) prototype and is marked as having
__attribute__(malloc), returning memory that doesn't alias anything else
etc...  Hence the compiler worries about both the __builtin_alloca and
alloca, and GCC assumes that in this case __builtin_alloca could otherwise
fallback to using alloca.  I believe this is truly the only exception, as
things like __builtin_constant_p don't have a corresponding "constant_p"
API.

I've even given some thought to "setjmp" and "longjmp" which we currently
don't intercept.  I'd like to change their entries in builtins.def to be
DEF_LIB builtins, so that GCC generates inline implementations for them.
Currently we only do this for __builtin_setjmp and __builtin_longjmp.
However, these don't quite fall into the same category as alloca, as they
can theoretically be implemented in libc, whereas alloca generally can't.


> Figure this out and send in a followup patch.
We could in theory add another kind od builtin to builtins.def
specifically to handle alloca, but personally I'm think its both
simpler and cleaner to acknowledge that this is a "special case"
and stick with this single line test.

But I am open to listening to opposing arguments (and thoughts on
setjmp and longjmp).

Roger
--