This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Clean up builtin expansion logic


Fergus Henderson <fjh@cs.mu.OZ.AU> writes:

> On 05-Aug-2003, Zack Weinberg <zack@codesourcery.com> wrote:
>> 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.
>
> These functions are documented (in gcc/builtins.c in the GCC source code)
> as taking for their parameter a pointer to an array of five words,
> i.e. `typedef void *builtin_jmpbuf_t[5]', rather than a jmpbuf_t.
> As I understand it, this is not necessarily compatible with a
> jmpbuf_t, so you can't call setjmp() and then jump back to it using
> __builtin_longjmp(), or call __builtin_setjmp() and then jump back to
> it using longjmp().
>
> Apart from that, the __builtin_ versions are the same as the standard
> versions, except that they are more efficient, and that they have two
> restrictions:
> 	1.  The second argument to __builtin_longjmp() must always be `1'.
> 	2.  The call to __builtin_longjmp() must not be in the same
> 	    function as the call to __builtin_setjmp().
>
> (Or at least those are the only restrictions that Richard Henderson was
> aware of when he wrote <http://gcc.gnu.org/ml/gcc/2000-12/msg00828.html>.)

Okay, so my understanding is out of date, but it is still the case
that we cannot legitimately optimize setjmp() into __builtin_setjmp().

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]