I'm jumping into the middle of this thread without having read all of it, but it appears to explore various issues which I am already familiar with, so I'll just say my piece and hope it's not already covered. I just noticed the thread (and that I had been Cc'ed a while back and missed that fact) in my Haskell-related mail folder... Don't have time to fully catch up on it right now, sorry.
First, I would recommend using clang as the backend rather than llvm-gcc - they are two separate compilers. Second, I have a patch which makes the necessary build-system changes to do exactly that, smoothly detecting the situations we care about through some autoconf evilness and so on, and have been postponing submitting it because I'm terrified of git. My patch doesn't resolve the pinned-register-variable issue, and runs into another issue entirely, so it still won't fix the build, but it's a necessary step on the way. The other issue is that cpp, whether the llvm-gcc version or the clang version, does not work for us. Only gcc cpp fills our needs, and essentially only by the coincidence that it allows the technically-invalid double-tick syntax that is used in Template Haskell code, in particular in dph. To cpp, this looks like a character literal of zero length, which is of course not legitimate C; clang's cpp, upon encountering it, produces an error message that can't be disabled, and does not produce meaningful output. llvm-gcc's cpp doesn't even get that far in the build, although I don't remember what the exact problem was; I don't think we want to mix a cc and cpp from two different compilers in any event. What we really need is our own preprocessor which understands Haskell's syntax rules, but it's not clear whether this is viable in a small amount of time; hscpp is LGPL, which I believe means we can't use it, and it would also probably need modification. I can see that a cpp-like preprocessor is probably not a huge amount of work to write, so our best strategy might be to write an entirely new one to be part of ghc. On the other hand, Mac OS X Lion comes out sometime in July, so we don't really have a lot of time to do this if we don't want to leave Mac users unable to build. I'm ready and willing to take up the task of writing a pp if people agree that it's what we want, but obviously I don't want to invest the effort otherwise. There might be some simple kludge (turn off dph? heh) which would work around the issue for the immediate future, I haven't looked too deeply into that. I do think we need pthread_getspecific() for now, even despite the efficiency hit. It's the only really portable way to do what we want. My build-system changes, which I have prepared extensive documentation for, define a new preprocessor variable that I think I called CC_FLAVOR, which is set to the string "gcc" or "clang", so we can conditionalize on that. >>> If we could move to clang (on OS X) that would be ideal, but as I wrote >>> above I seriously doubt that Apple will entirely remove gcc (at least not >>> before whatever cat comes after Lion). So, for the time being, and until >>> we can use clang, I think it would be wise to use 'gcc-4.2' as a default on >>> OS X (instead of 'gcc', which appears to morph into llvm-gcc soon). If we >>> do that for GHC 7.2, then GHC 7.2 won't break once Apple flips the sym link >>> over. Doesn't exist under that name on Lion. You have to reference it by its full name which includes the architecture. And I obviously have no information on this score, but I could see llvm-gcc going away before OS X 10.8 Asian Leopard Cat (or whatever), given that it is both deprecated by upstream and not really fully compatible with gcc in any event, so I really think moving to clang is the right approach. -- Dan Knapp "An infallible method of conciliating a tiger is to allow oneself to be devoured." (Konrad Adenauer) _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
