Re: [PATCH] Clean up builtin expansion logic

["Zack Weinberg" <zack at codesourcery dot com>]

Roger Sayle <roger@eyesopen.com> writes:

>>         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.

Ah, I see.

We have lots of other builtins that don't correspond to library
functions; it just _happens_ that they all have names that start
with __builtin_... I wonder if you could get around this with
two DEF_whatever_BUILTIN entries, one for "__builtin_alloca" and one
for "alloca" ... except then they'd get different BUILT_IN_* codes...

you're right, this probably doesn't need fixing.


> 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.

Note that setjmp and longjmp do not do the same thing as
__builtin_setjmp and __builtin_longjmp; it is my understanding that
the latter are only useful for implementing sjlj EH, not for user use.

zw