gcc labels as first class values
Markus Mock
gcc allows labels as first class values. Hence the appended code
works. However, the info says about that:
" You can use this mechanism to jump to code in a different function.
If you do that, totally unpredictable things will happen. The best
way to avoid this is to store the label address only in automatic
variables and never pass it as an argument."
Are there any guarantees that if you do not use local variables (as in
the example below) it will work as expected? Is it also clever enough
NOT to move loop invariant code outside of the loop if the loop label
had the address taken (and hence could be jumped to from outside the
function as in the example below)?
I tried the code below and it does not seem to move the invariant code
(x = 10) outside of the loop. If you do not take the address of the
label it will do it however. Can that behavior safely be assumed?
--
-- Markus U. Mock
mo...@erix.ericsson.se
================code to follow============================
#include <stdio.h>
#include <assert.h>
static void* labels[3];
static int first =1;
static int i=0, x=0;
void f1() {
if (first) {
printf("Initializing labels table\n");
labels[0] = && F1;
labels[1] = && F2;
first = 0;
return;
}
F1:
printf("Entrypoint 1\n");
i = 0;
F2:
x = 10;
i = i+1;
if (i <10) goto F2;
printf("x = %d\n",x);
goto *labels[2];
}
void main() {
void *label;
printf("Now we go to label L1\n");
label = && L1;
labels[2] = && L2;
goto *label;
assert(0);
L1:
printf("here is L1\n");
f1();
goto *labels[1];
L2:
printf("done\n");
}
Fergus Henderson
>gcc allows labels as first class values. Hence the appended code
>works. However, the info says about that:
>
>" You can use this mechanism to jump to code in a different function.
>If you do that, totally unpredictable things will happen. The best
>way to avoid this is to store the label address only in automatic
>variables and never pass it as an argument."
>
>Are there any guarantees that if you do not use local variables (as in
>the example below) it will work as expected?
There are no *guarantees*.
I'll give you a money-back guarantee, though, if you like ;-)
Anyway, regardless, it does work - I have the code to prove it!
It is certainly not the most portable code however. For example on Irix 5.2
it doesn't work with shared libraries - you have to specify -non_shared.
But it doesn't cause any trouble on Solaris 5.x.
>Is it also clever enough
>NOT to move loop invariant code outside of the loop if the loop label
>had the address taken (and hence could be jumped to from outside the
>function as in the example below)?
>
>I tried the code below and it does not seem to move the invariant code
>(x = 10) outside of the loop. If you do not take the address of the
>label it will do it however. Can that behavior safely be assumed?
Yes. This might perhaps break in future releases of gcc, if the
optimizer gets "smarter". However, it will always be possible to
defeat such "optimizations" if such a situation should arise,
by inserting appropriately obfuscatory code.
If you want an example of a compiler which generates C code using
these techniques, look out for the announcement of the public release
of the Mercury compiler.
--
Fergus Henderson
f...@cs.mu.oz.au
http://www.cs.mu.oz.au/~fjh
PGP key fingerprint: 00 D7 A2 27 65 09 B6 AC 8B 3E 0F 01 E7 5D C4 3F