Opened 2 years ago

Closed 2 years ago

Last modified 9 months 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 Test Case:
Blocked By: Blocking: #7602
Related Tickets: Differential Revisions:

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 (16)

comment:1 Changed 2 years ago by aseipp@…

commit 213e1c71e8c574e989f463ca623bef6d2dcccea6

Author: Austin Seipp <[email protected]>
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 <[email protected]>

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

comment:2 Changed 2 years ago by aseipp@…

commit 61e8d5df26522b01922bc5358b9c233de0d1fc29

Author: Austin Seipp <[email protected]>
Date:   Sun Feb 10 02:24:28 2013 -0600

    Better detection of clang in ./configure. Issue #7678.
    
    Signed-off-by: Austin Seipp <[email protected]>

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

comment:3 Changed 2 years ago by igloo

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

comment:4 Changed 2 years ago by lelf

  • Cc anton.nik@… added

comment:5 Changed 2 years ago by carter

  • Blocking 7929 added

comment:6 Changed 2 years ago by igloo

  • Blocking 7929 removed

comment:7 Changed 2 years 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 2 years 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 2 years 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 2 years 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 2 years 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 2 years 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 23 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 23 months ago by carter

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

ghc works

comment:15 follow-up: Changed 16 months ago by hvr

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

comment:16 in reply to: ↑ 15 Changed 9 months ago by thomie

Replying to hvr:

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

The followup email let's me believe this issue is really fixed now.

Note: See TracTickets for help on using tickets.