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
