HELP: GCC 2.5.8 Dead Code Elimination Bug?
Bruce W. Bigby (963081)
While writing some code that relies on setjmp and longjmp, I discovered a problem.
Let me give you some background. I have this routine that uses setjmp and longjmp
to control program flow. It first calls setjmp to save the environment. It switches
off the return value of setjmp to determine which case to follow next. The code
in case 0/1 conditionally, when local is true, performs a longjmp to case 2. Case
2 sets local to false and performs a longjmp back to case 0/1. When I turn on
optimization, using GCC 2.5.8's -O option, the program enters an infinite loop,
only to emerge with a control-c. What appears to be happening is that GCC thinks
that the assignment, local = 0, is dead code. As a result, it gets rid of it. This
elimination of the statement causes the infinite loop because case 0/1 never gets
the hint that it should terminate. I understand this problem. However, if I replace
the statement, local = 0, with a function that accepts an address of an integer and
sets it to zero, such as SetZero(&local), the problem still does not go away. Normally, a compiler could not safely remove a function call such as this because
it would not know what else the function might be doing. The only way it could
determine to remove the function is if it examined SetZero's contents and inlined it.
GCC's inline processing might, again, arrive at the conclusion that the use of the
local variable, once, in the assignment SetZero(&local) is still dead code. How
can I get around this problem yet still obtain the benefits of optimization? I, at
least, want an optimization that eliminates seemingly useless code, such as statements
that assign variables to themselves. For example, in looking at unoptimized assembler
source, I see statements of the form, x = x. GCC, and any compiler, could definitely
eliminate this code.
Bruce
P.S. Here's the code...
#inclue <stdlib.h>
#include <setjmp.h>
static jmp_buf env;
void
SetZero(intAddr)
int* intAddr;
{
*intAddr = 0;
}
void
DeadCodeEliminationConflict(void)
{
int local = 1;
switch(setjmp(env)) {
case 0:
case 1:
printf("case 0/1...\n");
if (local) {
longjmp(env, 2);
}
break;
case 2:
printf("case 2...\n");
local = 0; /* GCC 2.5.8 thinks this is dead code */
/* SetZero(&local); Is this dead code too? */
longjmp(env, 1);
default:
printf("Unhandled case...\n");
break;
}
}
main(int argc, char** argv)
{
DeadCodeEliminationConflict();
exit(0);
}
S. Lee
Bruce W. Bigby (963081) <bi...@ess.mc.xerox.com, bruce...@aol.com> wrote:
>
>What appears to be happening is that GCC thinks
>that the assignment, local = 0, is dead code.
I haven't looked at the asm output, but I don't think this is the case.
It is probably just some interaction of setjmp() and longjmp() with
variables on the stack. Declaring local as volatile works.
Stephen
Bakery Crafts
>While writing some code that relies on setjmp and longjmp ...,
<stuff deleted ...>
>least, want an optimization that eliminates seemingly useless code,
> int local = 1;
^-- Maybe add the 'volatile' keyword here ? (Spell it
correctly, though)
I believe that the 'volatile' keyword is a cue to the compiler that
the variable is a sentinal of some sort, perhaps even in the case of
a pointer, mapped to a hardware register or something. At least that's
my understanding of it. If you supply that keyword, maybe the optimizer
will stop messing with it.
Curt Eckhart
cu...@bkrycft.com