Hi all,
I have an interesting problem with gcc optimizing "away" an automatic variable
in a function which uses setjmp/longjmp in a macro-based exception processing
framework. Here's some example code (just to illustrate the problem, I haven't
tested this code):
#include <stdlib.h>
#include <stdio.h>
#include <setjmp.h>
#define EXC_TRY 1
#define EXC_CATCH 2
func()
{
const char *p = NULL; /*** auto variable ***/
{
jmp_buf exc_jmp_buf;
int exc_state;
if (setjmp(exc_jmp_buf) == 0) { /*** setjmp() ***/
exc_state = EXC_TRY;
} else {
exc_state = EXC_CATCH;
}
if (exc_state == EXC_TRY) { /*** TRY BLOCK ***/
bsdApp = "some value";
}
if (exc_state == EXC_CATCH) { /*** CATCH BLOCK ***/
puts(bsdApp);
}
}
}
As far as the optimizer is concerned, it's completely impossible that both the
TRY and the CATCH block may ever be executed -- exc_state can't have two values
at the same time and it doesn't change between the two blocks. As a result, it
effectively uses two different variables: the TRY block uses a stack variable,
the CATCH block uses a constant ininitialized to 0.
However, the execution path might jump back to the location of the setjmp()
call.
The big question now is whether this is something the optimizer should detect
(i.e. treat _setjmp() like a label assuming there will be a corresponding goto,
even if the longjmp() is outside of the function) or whether this is an unusual
application of setjmp/longjmp which is beyond the optimizer specs.
Oh yes, the optimization causing the variable to be optimized away is
"tree-dominator-opts"
Thanks,
--Christian
--
Summary: Optimizer doesn't see setjmp()
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cm1 at mumac dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44947
