Forcing register assignments before non-conditional blocks

Simon Kagstrom
Sat Apr 19 17:59:00 GMT 2008


For a project of mine [1], I'm using Java exceptions in C code and have
implemented a construct similar to Java try/catch blocks. I have a
slight problem with GCC optimization though. An example to illustrate
my problem:

  NOPH_try(handler, (void*)5)
      int w = NOPH_GameCanvas_getWidth(-1); /* Throws an exception */
      global_var = w;
    } NOPH_catch();

    if (global_var ...)

this code fails because GCC loads the address of 'global_var' to a
register just before the assignment to it, and then reuses this
register in the branch later. The problem here is that the assignment
might never be done if an exception is caused by
"NOPH_GameCanvas_getWidth", when execution will just continue after

I understand that this is nothing wrong with GCC - just a consequence
of my abuse of it. However, I'm wondering if there is a way to force
the address assignment out of the "exception block" e.g., through a
jump (which can never happen) from NOPH_try to NOPH_catch?

NOPH_try and NOPH_catch are macros and currently looks like this

   #define NOPH_try(callback, arg) do { \
     int tmp;                           \
     asm volatile("la %0, 0\n"          \
                  "lw %0, 0(%0)\n"      \
                  "beqz %0, 128f\n"     \
     : "=r"(tmp)                        \
     );                                 \
     __NOPH_try(callback, arg);         \
   } while(0); do

   extern void __NOPH_catch(void);
   #define NOPH_catch() while(0); do {  \
     asm volatile("128:\n");            \
     __NOPH_catch();                    \
   } while(0)

i.e., with a jump from try to catch. This doesn't work however, since
GCC doesn't recognize the constraints posed by the assembly code. Just
adding the corresponding C code with a goto from NOPH_try to NOPH_catch
also doesn't work since there might be several try/catch pairs in a
function (leading to the label being multiply defined).

Any ideas?

// Simon

More information about the Gcc-help mailing list