Opened 15 months ago

Closed 10 months ago

Last modified 3 weeks ago

#7678 closed bug (fixed)

GHC should compile cleanly with clang

Reported by: thoughtpolice Owned by: thoughtpolice
Priority: high Milestone: 7.8.1
Component: Compiler Version: 7.7
Keywords: clang Cc: anton.nik@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Building GHC failed Difficulty: Unknown
Test Case: Blocked By:
Blocking: #7602 Related Tickets:

Description

I'm running into several difficulties (which I'll catalog shortly) building GHC HEAD with Clang 3.2. These mostly seem to be difficulties relating to the preprocessor and the fact clang does not really respect -traditional-cpp mode, and that it is stricter than gcc about whitespace and whatnot too. This means code like:

{-# RULES

 "thing" ...

  #-}

becomes invalid: clang is strict about the fact that preprocessor definitions must occur on the beginning of a line. There seems to be a bug in the preprocessor directive source code to this effect (that it doesn't handle whitespace before a directive.) It's quite unfortunate, because we do this a lot.

This also causes build failures in the parser due to some crazy CPP hackery we do. I'll follow up with that shortly.

As a workaround, we may have to force CPP to just continue being cpp which will Do The Right Thing, while CC will use clang instead. Or we'll have to have some script that seds whitespace out or something.

This currently blocks #7602 since I can't test my fix otherwise.

Change History (15)

comment:1 Changed 15 months ago by aseipp@…

commit 213e1c71e8c574e989f463ca623bef6d2dcccea6

Author: Austin Seipp <aseipp@pobox.com>
Date:   Sun Feb 10 02:22:29 2013 -0600

    Make sure ./configure tests valid C99 programs. Issue #7678.
    
    Clang gives a big fat warning that there's no return value for the
    statement, since the prototype defaults to 'int'.
    
    Signed-off-by: Austin Seipp <aseipp@pobox.com>

 aclocal.m4 |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

comment:2 Changed 15 months ago by aseipp@…

commit 61e8d5df26522b01922bc5358b9c233de0d1fc29

Author: Austin Seipp <aseipp@pobox.com>
Date:   Sun Feb 10 02:24:28 2013 -0600

    Better detection of clang in ./configure. Issue #7678.
    
    Signed-off-by: Austin Seipp <aseipp@pobox.com>

 aclocal.m4      |   19 +++++++++++++++----
 configure.ac    |    8 +++++++-
 mk/config.mk.in |    4 ++++
 3 files changed, 26 insertions(+), 5 deletions(-)

comment:3 Changed 13 months ago by igloo

  • Difficulty set to Unknown
  • Milestone set to 7.8.1
  • Priority changed from normal to high

comment:4 Changed 13 months ago by lelf

  • Cc anton.nik@… added

comment:5 Changed 11 months ago by carter

  • Blocking 7929 added

comment:6 Changed 11 months ago by igloo

  • Blocking 7929 removed

comment:7 Changed 10 months ago by carter

I'm able to suppress the spurious CPP warnings clang gives by wrapping clang in the following script

and then on my mac I can use the patched Clang instead of gcc to build my haaskell code fine with GHC 7.6.3

#! /bin/sh
clang  -Wno-unicode  -Wno-trigraphs -Wno-invalid-pp-token  -Wno-return-type $@

comment:8 Changed 10 months ago by carter

i'm seeing the following build error when i try to build ghc head using clang head:

In file included from compiler/basicTypes/DataCon.lhs:49:0: 

compiler/HsVersions.h:29:5:
     error: '#' is not followed by a macro parameter
{-# NOINLINE name #-};             \
    ^

compiler/HsVersions.h:34:5:
     error: '#' is not followed by a macro parameter
{-# NOINLINE name #-};              \
    ^
2 errors generated.
make[1]: *** [compiler/stage1/build/.depend-v.haskell] Error 1

comment:9 Changed 10 months ago by carter

the pragma problem i just posted seems to happen whether or not i I use quick or quick-llvm , and gcc or clang....

comment:10 Changed 10 months ago by thoughtpolice

  • Resolution set to fixed
  • Status changed from new to closed

HEAD as of commit 1a9832 can now build a working stage1 and stage2 compiler when using Clang. primitive fails to build due to a Clang 'bug' descibed in http://llvm.org/bugs/show_bug.cgi?id=16371 but this can be worked around. I'll be committing this fix later, and with that a full stage2 build can happen.

I'm marking this ticket closed; further problems will be put into other tickets.

comment:11 Changed 9 months ago by pyrtsa

Hi, I think this bug should be reconsidered. It looks like the upcoming version of Clang won't support llvm-gcc and its -traditional option at all. I wrote my notes about the issue in https://gist.github.com/pyrtsa/6213784 if it helps.

comment:12 Changed 9 months ago by thoughtpolice

Clang does not 'support' traditional mode in the sense it does not completely mimmick GCC, because to do so would be insane. However, we can get by with it in the latest version of Clang HEAD.

This bug is only for GHC HEAD. 7.6.3 simply will not work with Clang I'm afraid without hacking things. There are several very important changes that were needed in the source for *both* projects in order to make them compatible, so it's not surprising you have to do weird things to make it all work in some hacky way.

All that said, I guess I'll have to bite the stupid bullet and get an ADC account since Apple likes to mess things up so much.

comment:13 Changed 8 months ago by refold

@thoughtpolice

Did you manage to compile Cabal with Clang? GHC depends on Cabal, but according to this bug report Cabal currently fails to build when Clang is used as a preprocessor.

comment:14 Changed 8 months ago by carter

@refold, i've comented on the issue. Its fixed, its more subtle than you expect.

ghc works

comment:15 Changed 3 weeks ago by hvr

fyi, I'm afraid the situation has changed; see this email for details.

Note: See TracTickets for help on using tickets.