GCC, Mac OS X & the future
davidterei at gmail.com
Tue Jun 28 20:20:48 CEST 2011
I've always thought it would be an interesting idea to try to compile
GHC using Clang, using the GHC calling convention support in LLVM to
support pinned register variables. Maybe this is the time to try this
idea if someone has the time for it.
On 28 June 2011 05:20, Dan Knapp <dankna at gmail.com> wrote:
> 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
> Cvs-ghc at haskell.org
More information about the Cvs-ghc