This is just a tracking bug that points out that we don't currently support the
'address of a label' GCC extension.  This extension is often used to make
'threaded' interpreters.   It would be good to support this eventually.

Here's a simple example:

---
int code[]={0,0,0,0,1};
void foo(int x) {
  volatile int b;
  b = 0xffffffff;
}
void bar(int *pc) {
  static const void *l[] = {&&lab0, &&end};

  foo(0);
  goto *l[*pc];
 lab0:
  foo(0);
  pc++;
  goto *l[*pc];
 end:
  return;
}
int main() {
  bar(code);
  return 0;
}
---

-Chris

Do you think we should have labels as values, like in gcc, then? Or should we
do some kind of l33t 
transformation that lowers the uses of labels as values to switch or branch
statements or something?

Yes, we will have a leet transformation.  I don't intend to extend LLVM to
support this.  :)

-Chris

This is ugly.  Apparently GCC allows one to do stuff like this as well.  Cute!
:)

  static const int array[] = { &&foo - &&foo, &&bar - &&foo,                   

                             &&hack - &&foo };
  goto *(&&foo + array[i]);

I'm looking into adding support for this now.

-Chris

As it turns out, GCC doesn't implement exceptions or destructors correctly in
the presence of indirect gotos either.  Here's a testcase.  When we implement it
correctly and GCC doesn't, I will file a GCC bug report.

-Chris

---
#include <stdio.h>

namespace {
  struct S {
    int V;
    S(int v) : V(v) {
      printf("create %d\n", V);
    }
    ~S() {
      printf("destroy %d\n", V);
    }
  };
}

int main() {
  static const void *L[] = {&&L1, &&L2, &&L3, &&L4, 0 };
  unsigned i = 0;
  S a(0);  
L1:
  S b(1);
L2:
  S c(2);
L3:
  S d(3);
  goto *L[++i];
L4: return 0;
}
---

This is now implemented.  Primary patch here:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040315/013179.html

Testcases here:
test/Regression/CFrontend/2004-03-15-SimpleIndirectGoto.c
test/Programs/SingleSource/Regression/C/2004-03-15-IndirectGoto.c 

Note that this does not work correctly in the presence of exceptions and C++
cleanups, but then again, neither does the native GCC compiler.

This GCC extension is widely used to implement "threaded interpreters", so
supporting it is useful. :)

-Chris