GHC, Clang & XCode 4.2
as at hacks.yi.org
Wed Oct 5 10:46:25 CEST 2011
There has been recent discussion on the Homebrew bug tracker
concerning the upcoming XCode 4.2 release by Apple, which has
apparently just gone GM (meaning they're going to make a real release
on the app store Real Soon Now.)
The primary concern is that XCode will no longer ship GCC 4.2 at all,
it seems. XCode 4.0 & 4.1 merely set 'llvm-gcc' as the default
compiler, and GHC's `configure` script was adjusted to find the
`gcc-4.2` binary. If you have old XCode's installed, then you may have
the binaries laying around, but I doubt they'll be on your $PATH, and
anybody doing a fresh install is SOL.
It seems Clang 3.0 will now be the default compiler, with llvm-gcc as
a deprecated option, probably removed in XCode 4.3. It doesn't matter
really, because both of them do not work with GHC, because of its use
of either A) Global register variables of any kind, or B) the __thread
David Peixotto did some work on this not too long ago as the issue of
compiling with Clang was raised. His branches include changes which
make the 'gct' variable use pthread_getspecific rather than __thread
for TLS and then as an optimization use inline ASM to grab the value
out of the variable, with an impact of about 9% it seems, but that's
on nofib and I don't know if it was -threaded. He also included a
version which passes the 'gct' around as a parameter to all GCC
functions which is a bit uglier but may give some better performance I
guess. (The discussion is from here IIRC.) I suppose the real perf
killer here is probably -threaded code.
Was there ever any decision on which route to take for this issue? The
parameter passing solution looks quite uglier IMO but it may be
necessary for performance.
I'm just posting this here as a reminder as this is probably going to
become a problem pretty quickly for anybody who uses Lion or modern
XCode and also likes using GHC, so it should probably be sorted out.
:) I'm still on SL using XCode 4 so it's not an issue for me, but it
will be for any future Mac endeavors. Hopefully they get support for
__thread or something equivalent soon, because nobody likes
performance hits, but it doesn't seem like we have a choice.
More information about the Glasgow-haskell-users