<div dir="ltr">Awesome!<div><br></div><div style>I&#39;m actually hitting another CPP bug right now in building ghc head with clang head, also I&#39;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.</div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 19, 2013 at 12:44 AM, Austin Seipp <span dir="ltr">&lt;<a href="mailto:aseipp@pobox.com" target="_blank">aseipp@pobox.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
As of commit 5dc74f it should now be possible to build a working<br>
stage1 and stage2 compiler with (an extremely recent) Clang. With some<br>
caveats.<br>
<br>
You can just do:<br>
<br>
$ CC=/path/to/clang ./configure --with-gcc=/path/to/clang<br>
$ make<br>
<br>
I have done this work on Linux. I don&#39;t expect much difficulty on Mac<br>
OS X, but it needs testing. Ditto with Windows, although Clang/mingw<br>
is considered experimental.<br>
<br>
The current caveats are:<br>
<br>
 * The testsuite will probably fail everywhere, because of some<br>
warnings that happen during the linking phase when you invoke the<br>
built compiler. So the testsuite runner will probably be unhappy.<br>
Clang is very noisy about unused options, unlike GCC. That needs to be<br>
fixed somewhere in DriverPipeline I&#39;d guess, but with some<br>
refactoring.<br>
 * Some of the stage2 libraries don&#39;t build due to a Clang bug. These<br>
are vector/primitive/dph so far.<br>
 * There is no buildbot or anything to cover it.<br>
<br>
You will need a very recent Clang. Due to this bug (preventing<br>
primitive etc from building,) you&#39;ll preferably want to use an SVN<br>
checkout from about 6 hours ago at latest:<br>
<br>
<a href="http://llvm.org/bugs/show_bug.cgi?id=16363" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=16363</a><br>
<br>
Hilariously, this bug was tripped on primitive&#39;s Data.Primitive.Types<br>
module due to some CPP weirdness. But even with a proper bugfix and no<br>
segfault, it still fails to correctly parse this same module with the<br>
same CPP declarations. I&#39;m fairly certain this is another bug in<br>
Clang, but I might be wrong. I&#39;m trying to isolate it. Unfortunately<br>
Clang/LLVM 3.3 was just released and it won&#39;t see bugfix releases. But<br>
it will *probably* work if we just get rid of the CPP tomfoolery in<br>
primitive. I&#39;ll be testing it in the next few days to see if we can<br>
get 3.3 supported. (I&#39;m sort of kicking myself in the head for not<br>
doing this a week or two ago...)<br>
<br>
Anyway, there are some rough edges but it should be in shape for 7.8 I<br>
hope. It should be especially welcome for Mac users. (I&#39;m also hoping<br>
modern Macs could even go all-clang-all-the-time if my fix for #7602<br>
can go in soon...)<br>
<br>
PS. If you use ASSERT, I just fixed a lot of instances of using that<br>
macro, involving whitespace between the name and arguments (commit<br>
d8ee2b.) Clang does not forgive you for this. Should I note this<br>
anywhere for the future in the wiki or something?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Regards,<br>
Austin - PGP: 4096R/0x91384671<br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
</font></span></blockquote></div><br></div>