http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #10 from Leif Leonhardy <bugfeed at online dot de> 2013-04-18 01:17:31 UTC --- "One proposed requirement on setjmp is that it be usable like any other function, that is, that it be callable in *any* expression context, and that the expression evaluate correctly whether the return from setjmp is direct or via a call to longjmp. Unfortunately, any implementation of setjmp as a conventional called function cannot know enough about the calling environment to save any temporary registers or dynamic stack locations used part way through an expression evaluation. [...] The temporaries may be correct on the initial call to setjmp, but are not likely to be on any return initiated by a corresponding call to longjmp. These considerations dictated the constraint that setjmp be called only from within fairly simple expressions, ones not likely to need temporary storage. An alternative proposal considered by the C89 Committee was to require that implementations recognize that calling setjmp is a special case, and hence that they take whatever precautions are necessary to restore the setjmp environment properly upon a longjmp call. This proposal was rejected on grounds of consistency: implementations are currently allowed to implement library functions specially, but no other situations require special treatment." So according to this (The C99 Rationale [1], page 139 ff., likewise the Single UNIX Specification), here setjmp() is simply used in an invalid context (i.e., in an assignment statement). ;-) Still, with -Og at least, GCC 4.8.0 produces wrong code even if setjmp() is used in an "allowed" context (as in e.g. if (setjmp(...)>0) ..., or switch (setjmp(...)) { ... }), and no matter whether n is declared volatile or not. [1] http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf