llvm-gcc hang on OS X 10.7

[Jim Ursetto]

ddp may have found the root cause of hanging of chicken binaries compiled with llvm-gcc: ​http://blog.phusion.nl/2011/12/30/xcode-4-ships-a-buggy-compiler/

The current workaround is to force gcc-4.2 during compilation. However, Xcode 4.2 (shipped in November) removes plain gcc-4.2. Since this breaks Ruby's garbage collector, I assume either Apple will provide a fix or Ruby will work around it (which fix we should adopt).

The usual solution for non-alloca platforms is to use a stub function to take the address of a local variable (requiring compiler support for noinline). If the workaround becomes necessary, I would want to target it as narrowly as possible, as it is ugly. The remaining question is how narrowly it can be targeted.

[Jim Ursetto]

Ignore the stub function comment, it's not really right. So far I've attempted to simulate alloca(0) via retrieving the value of SP using inline assembly. This is basically what Ruby Enterprise Edition falls back to when alloca is not available or broken. However, llvm-gcc appears to treat SP and BP differently than plain gcc, so I'm not yet convinced this approach is sound.

[Jim Ursetto]

Attached two patches fix the hangs on LLVM with optimization enabled. This fix is also required on Linux (tested with Ubuntu 10.04 and their llvm-gcc-4.2 package (LLVM 2.7)); my assumption is that the build success on Linux reported by Felix was done with optimization disabled.

As an interesting data point, building Chicken after make spotless is much faster when using LLVM chicken: 123sec vs 161sec here. Considering that includes the runtime for both "chicken" and "gcc", the speedup for chicken must be significant.

[Jim Ursetto]

Confirmed it works with clang (llvm 3.0) on OS X as well, although that wasn't really in doubt.

[felix winkelmann]

Thanks - patches are pushed. I actually forgot to sign off.