PSA: GHC can now be built with Clang

[Austin Seipp]

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 <ggreif at gmail.com> 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 <carter.schonwald at gmail.com> 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 <aseipp at pobox.com> 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
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>



-- 
Regards,
Austin - PGP: 4096R/0x91384671