Yes, we're using -undef -traditional. We're also suppressing some extra warnings from Clang concerning other things; you can see my recent commits.
I have filed a related LLVM bug, regarding the preprocessor behavior that affects primitive: http://llvm.org/bugs/show_bug.cgi?id=16371 I have worked around this bug manually inside primitive, and with it, I have been able to do a complete stage2 build with all libraries up to DPH, so we're extremely close! I'll keep hacking away in the mean time. On Wed, Jun 19, 2013 at 2:38 AM, Gabor Greif <[email protected]> wrote: > Please make sure that all bugs are reported back to the Clang devs. > They are usually very fast in fixing them. > > I assume that the ${CPP} is in traditional mode? > > Cheers, > > Gabor > > > On 6/19/13, Carter Schonwald <[email protected]> wrote: >> Awesome! >> >> I'm actually hitting another CPP bug right now in building ghc head with >> clang head, also I'll reach out to an apple dude i know to find out if we >> can get any help from them on this or the related TLS issue. >> >> >> On Wed, Jun 19, 2013 at 12:44 AM, Austin Seipp <[email protected]> wrote: >> >>> Hi all, >>> >>> As of commit 5dc74f it should now be possible to build a working >>> stage1 and stage2 compiler with (an extremely recent) Clang. With some >>> caveats. >>> >>> You can just do: >>> >>> $ CC=/path/to/clang ./configure --with-gcc=/path/to/clang >>> $ make >>> >>> I have done this work on Linux. I don't expect much difficulty on Mac >>> OS X, but it needs testing. Ditto with Windows, although Clang/mingw >>> is considered experimental. >>> >>> The current caveats are: >>> >>> * The testsuite will probably fail everywhere, because of some >>> warnings that happen during the linking phase when you invoke the >>> built compiler. So the testsuite runner will probably be unhappy. >>> Clang is very noisy about unused options, unlike GCC. That needs to be >>> fixed somewhere in DriverPipeline I'd guess, but with some >>> refactoring. >>> * Some of the stage2 libraries don't build due to a Clang bug. These >>> are vector/primitive/dph so far. >>> * There is no buildbot or anything to cover it. >>> >>> You will need a very recent Clang. Due to this bug (preventing >>> primitive etc from building,) you'll preferably want to use an SVN >>> checkout from about 6 hours ago at latest: >>> >>> http://llvm.org/bugs/show_bug.cgi?id=16363 >>> >>> Hilariously, this bug was tripped on primitive's Data.Primitive.Types >>> module due to some CPP weirdness. But even with a proper bugfix and no >>> segfault, it still fails to correctly parse this same module with the >>> same CPP declarations. I'm fairly certain this is another bug in >>> Clang, but I might be wrong. I'm trying to isolate it. Unfortunately >>> Clang/LLVM 3.3 was just released and it won't see bugfix releases. But >>> it will *probably* work if we just get rid of the CPP tomfoolery in >>> primitive. I'll be testing it in the next few days to see if we can >>> get 3.3 supported. (I'm sort of kicking myself in the head for not >>> doing this a week or two ago...) >>> >>> Anyway, there are some rough edges but it should be in shape for 7.8 I >>> hope. It should be especially welcome for Mac users. (I'm also hoping >>> modern Macs could even go all-clang-all-the-time if my fix for #7602 >>> can go in soon...) >>> >>> PS. If you use ASSERT, I just fixed a lot of instances of using that >>> macro, involving whitespace between the name and arguments (commit >>> d8ee2b.) Clang does not forgive you for this. Should I note this >>> anywhere for the future in the wiki or something? >>> >>> -- >>> Regards, >>> Austin - PGP: 4096R/0x91384671 >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> [email protected] >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> -- Regards, Austin - PGP: 4096R/0x91384671 _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
