This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Clean up builtin expansion logic
On 05-Aug-2003, Roger Sayle <roger@eyesopen.com> wrote:
> 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.
Wouldn't there be ABI issues with expanding setjmp() and longjmp() inline?
In particular, a program needs to be able to call setjmp() in GCC-compiled
code and then pass the resulting jmpbuf_t to code compiler with some non-GCC
compiler than calls longjmp() on it. So we don't have any license to
change the representation of jmpbuf_t. That representation may be different
on different platforms or with different C libraries, so it wouldn't be
possible to inline setjmp() or longjmp() in a platform-independent way.
Also, on some platforms setjmp() and longjmp() save and restore the
signal mask, and on others they don't.
Were you thinking of introducing new target hooks (or something like that)
in order to be able to inline setjmp()/longjmp()?
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.