Building GHC head with clang on Mavericks

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Kazu Yamamoto (山本和彦)
Hi,

As I wrote in the following blog article, I could build GHC head on
Mavericks 20 days ago.

        http://d.hatena.ne.jp/kazu-yamamoto/20131028/1382921924

But I cannot build it recently:

----
"/usr/bin/ghc" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O  -package-db libraries/bootstrapping.conf   -i -iutils/genprimopcode/. -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen       -package array  -no-user-package-db -rtsopts      -odir utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir utils/genprimopcode/dist/build   -c utils/genprimopcode/dist/build/Lexer.hs -o utils/genprimopcode/dist/build/Lexer.o

<built-in>:2:2: Not in scope: `#'
make[1]: *** [utils/genprimopcode/dist/build/Lexer.o] Error 1
make[1]: *** Waiting for unfinished jobs....
shift/reduce conflicts:  46
reduce/reduce conflicts: 1
make: *** [all] Error 2
----

I seems to me that linemarkers generated by GCC(CPP) is not correctly
handled when alex is used. Note I can build GHC head on FreeBSD and
Linux.

I'm using clang with clang-xcode5-wrapper.hs.

Any suggestions?

--Kazu

Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Carter Schonwald
Hey Kazu,
Nick Partridge hit this recently and he's got PR's pending for Happy and
Alex https://github.com/simonmar/alex/pull/37 and
https://github.com/simonmar/happy/pull/12


On Mon, Nov 18, 2013 at 1:13 AM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:

> Hi,
>
> As I wrote in the following blog article, I could build GHC head on
> Mavericks 20 days ago.
>
>         http://d.hatena.ne.jp/kazu-yamamoto/20131028/1382921924
>
> But I cannot build it recently:
>
> ----
> "/usr/bin/ghc" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O  -package-db
> libraries/bootstrapping.conf   -i -iutils/genprimopcode/.
> -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen
> -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen
>     -package array  -no-user-package-db -rtsopts      -odir
> utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build
> -stubdir utils/genprimopcode/dist/build   -c
> utils/genprimopcode/dist/build/Lexer.hs -o
> utils/genprimopcode/dist/build/Lexer.o
>
> <built-in>:2:2: Not in scope: `#'
> make[1]: *** [utils/genprimopcode/dist/build/Lexer.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
> shift/reduce conflicts:  46
> reduce/reduce conflicts: 1
> make: *** [all] Error 2
> ----
>
> I seems to me that linemarkers generated by GCC(CPP) is not correctly
> handled when alex is used. Note I can build GHC head on FreeBSD and
> Linux.
>
> I'm using clang with clang-xcode5-wrapper.hs.
>
> Any suggestions?
>
> --Kazu
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131118/17e72049/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Kazu Yamamoto (山本和彦)
Hi Carter,

> Nick Partridge hit this recently and he's got PR's pending for Happy and
> Alex https://github.com/simonmar/alex/pull/37 and
> https://github.com/simonmar/happy/pull/12

I'm not using GCC. (In my previous message, I made a typo. "GCC"
should be read as "clang"). So, I think that this is a different
problem.

--Kazu

Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Kazu Yamamoto (山本和彦)
In reply to this post by Kazu Yamamoto (山本和彦)
Hi,

Adding the "-v" option, GHC displays:

----
*** Checking old interface for main:Lexer:
*** Parser:
*** Renamer/typechecker:

<built-in>:2:2: Not in scope: `#'
----

"-keep-tmp-files" keeps generated .hscpp file. The beginning of the
generated .hscpp is:

----
# 1 "utils/genprimopcode/dist/build/Lexer.hs"
# 1 "<built-in>" 1
# 1 "utils/genprimopcode/dist/build/Lexer.hs" 2
{-# LANGUAGE CPP,MagicHash #-}
{-# LINE 2 "utils/genprimopcode/./Lexer.x" #-}
----

"<built-in>:2:2: Not in scope: `#'" in my previous message indicates
this line 2.

I don't know why Renamer/typechecker cannot handle this .hsccp file.

--Kazu

> Hi,
>
> As I wrote in the following blog article, I could build GHC head on
> Mavericks 20 days ago.
>
> http://d.hatena.ne.jp/kazu-yamamoto/20131028/1382921924
>
> But I cannot build it recently:
>
> ----
> "/usr/bin/ghc" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O  -package-db libraries/bootstrapping.conf   -i -iutils/genprimopcode/. -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen       -package array  -no-user-package-db -rtsopts      -odir utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir utils/genprimopcode/dist/build   -c utils/genprimopcode/dist/build/Lexer.hs -o utils/genprimopcode/dist/build/Lexer.o
>
> <built-in>:2:2: Not in scope: `#'
> make[1]: *** [utils/genprimopcode/dist/build/Lexer.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
> shift/reduce conflicts:  46
> reduce/reduce conflicts: 1
> make: *** [all] Error 2
> ----
>
> I seems to me that linemarkers generated by GCC(CPP) is not correctly
> handled when alex is used. Note I can build GHC head on FreeBSD and
> Linux.
>
> I'm using clang with clang-xcode5-wrapper.hs.
>
> Any suggestions?
>
> --Kazu

Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Kazu Yamamoto (山本和彦)
Hi,

> btw, is there really no whitespace before the '#' in line 2 ?

No space. The line starts with '#'.

For testing, I created a valid HS file using CPP and complied it with
GHC 7.6.3. A .hscpp file contains:

----
# 1 "a.hs"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "a.hs"
{-# LANGUAGE CPP #-}
----

The line 2 also starts with '#'.

Comparing this with the previous one, the difference is '1' in the end
of line.

----
# 1 "utils/genprimopcode/dist/build/Lexer.hs"
# 1 "<built-in>" 1
# 1 "utils/genprimopcode/dist/build/Lexer.hs" 2
{-# LANGUAGE CPP,MagicHash #-}
----

--Kazu

Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Kazu Yamamoto (山本和彦)
In reply to this post by Kazu Yamamoto (山本和彦)
Hi,

I can finally build GHC head on Mavericks. I gave up on clang and
installed GHC 4.8 with MacPorts.

Then, I compiled alex and happy with GHC 7.6.3/GHC 4.8. With this, I
can build GHC head.

This step is a MUST. If alex and happy are complied GHC
7.6.3/clang-wrapper, I cannot build GHC head with GHC 7.6.3/GHC 4.8.

--Kazu

> Hi,
>
> Adding the "-v" option, GHC displays:
>
> ----
> *** Checking old interface for main:Lexer:
> *** Parser:
> *** Renamer/typechecker:
>
> <built-in>:2:2: Not in scope: `#'
> ----
>
> "-keep-tmp-files" keeps generated .hscpp file. The beginning of the
> generated .hscpp is:
>
> ----
> # 1 "utils/genprimopcode/dist/build/Lexer.hs"
> # 1 "<built-in>" 1
> # 1 "utils/genprimopcode/dist/build/Lexer.hs" 2
> {-# LANGUAGE CPP,MagicHash #-}
> {-# LINE 2 "utils/genprimopcode/./Lexer.x" #-}
> ----
>
> "<built-in>:2:2: Not in scope: `#'" in my previous message indicates
> this line 2.
>
> I don't know why Renamer/typechecker cannot handle this .hsccp file.
>
> --Kazu
>
>> Hi,
>>
>> As I wrote in the following blog article, I could build GHC head on
>> Mavericks 20 days ago.
>>
>> http://d.hatena.ne.jp/kazu-yamamoto/20131028/1382921924
>>
>> But I cannot build it recently:
>>
>> ----
>> "/usr/bin/ghc" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O  -package-db libraries/bootstrapping.conf   -i -iutils/genprimopcode/. -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen       -package array  -no-user-package-db -rtsopts      -odir utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir utils/genprimopcode/dist/build   -c utils/genprimopcode/dist/build/Lexer.hs -o utils/genprimopcode/dist/build/Lexer.o
>>
>> <built-in>:2:2: Not in scope: `#'
>> make[1]: *** [utils/genprimopcode/dist/build/Lexer.o] Error 1
>> make[1]: *** Waiting for unfinished jobs....
>> shift/reduce conflicts:  46
>> reduce/reduce conflicts: 1
>> make: *** [all] Error 2
>> ----
>>
>> I seems to me that linemarkers generated by GCC(CPP) is not correctly
>> handled when alex is used. Note I can build GHC head on FreeBSD and
>> Linux.
>>
>> I'm using clang with clang-xcode5-wrapper.hs.
>>
>> Any suggestions?
>>
>> --Kazu

Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Carter Schonwald
Kazu. This is exactly the problem I linked to.  Could you try the proposed
patches to test if they allow builds to succeed with a wrapped clang on
your machine?

On Monday, November 18, 2013, Kazu Yamamoto wrote:

> Hi,
>
> I can finally build GHC head on Mavericks. I gave up on clang and
> installed GHC 4.8 with MacPorts.
>
> Then, I compiled alex and happy with GHC 7.6.3/GHC 4.8. With this, I
> can build GHC head.
>
> This step is a MUST. If alex and happy are complied GHC
> 7.6.3/clang-wrapper, I cannot build GHC head with GHC 7.6.3/GHC 4.8.
>
> --Kazu
>
> > Hi,
> >
> > Adding the "-v" option, GHC displays:
> >
> > ----
> > *** Checking old interface for main:Lexer:
> > *** Parser:
> > *** Renamer/typechecker:
> >
> > <built-in>:2:2: Not in scope: `#'
> > ----
> >
> > "-keep-tmp-files" keeps generated .hscpp file. The beginning of the
> > generated .hscpp is:
> >
> > ----
> > # 1 "utils/genprimopcode/dist/build/Lexer.hs"
> > # 1 "<built-in>" 1
> > # 1 "utils/genprimopcode/dist/build/Lexer.hs" 2
> > {-# LANGUAGE CPP,MagicHash #-}
> > {-# LINE 2 "utils/genprimopcode/./Lexer.x" #-}
> > ----
> >
> > "<built-in>:2:2: Not in scope: `#'" in my previous message indicates
> > this line 2.
> >
> > I don't know why Renamer/typechecker cannot handle this .hsccp file.
> >
> > --Kazu
> >
> >> Hi,
> >>
> >> As I wrote in the following blog article, I could build GHC head on
> >> Mavericks 20 days ago.
> >>
> >>      http://d.hatena.ne.jp/kazu-yamamoto/20131028/1382921924
> >>
> >> But I cannot build it recently:
> >>
> >> ----
> >> "/usr/bin/ghc" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O
>  -package-db libraries/bootstrapping.conf   -i -iutils/genprimopcode/.
> -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen
> -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen
>     -package array  -no-user-package-db -rtsopts      -odir
> utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build
> -stubdir utils/genprimopcode/dist/build   -c
> utils/genprimopcode/dist/build/Lexer.hs -o
> utils/genprimopcode/dist/build/Lexer.o
> >>
> >> <built-in>:2:2: Not in scope: `#'
> >> make[1]: *** [utils/genprimopcode/dist/build/Lexer.o] Error 1
> >> make[1]: *** Waiting for unfinished jobs....
> >> shift/reduce conflicts:  46
> >> reduce/reduce conflicts: 1
> >> make: *** [all] Error 2
> >> ----
> >>
> >> I seems to me that linemarkers generated by GCC(CPP) is not correctly
> >> handled when alex is used. Note I can build GHC head on FreeBSD and
> >> Linux.
> >>
> >> I'm using clang with clang-xcode5-wrapper.hs.
> >>
> >> Any suggestions?
> >>
> >> --Kazu
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <javascript:;>
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131118/743d167a/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Kazu Yamamoto (山本和彦)
Hi Carter,
SimonM, please read this message.

I will answer Carter's question and show a solution of my problem.

> Kazu. This is exactly the problem I linked to.  Could you try the proposed
> patches to test if they allow builds to succeed with a wrapped clang on
> your machine?

I installed nkpart's alex and happy with GHC/clang-wrapper. With this
alex and happy, I can build GHC head with GHC/GCC42. But I cannot
build GHC head with GHC/clang-wrapper.

Moreover, I can install happy and alex with GHC/clang-wrapper without
nkpart's patches.

I think that your problem is how to build alex and happy with
GHC/clang-wrapper. But my problem is how to compile HS files created
by alex and happy with GHC/clang-wrapper.

After deep investigation, I found the source of my problem. Consider
the following file created by CPP of clang or GCC:

----
# 1 "<built-inxxx>" 1
# 1 "templates/GenericTemplatexxx.hs" 2
{-# FOO
  #-}
----

% clang -E -undef -x assembler-with-cpp this_file
generates:

----
# 1 "test"
# 1 "<built-in>" 1
# 1 "test" 2
 # 1 "<built-inxxx>" 1

 # 1 "templates/GenericTemplatexxx.hs" 2

{-# FOO
  #-}
----

So, the line started with " #" cannot be treated by GHC. This is the
problem.

% clang -E -undef -x c this_file
generates:

----
# 1 "test"
# 1 "<built-in>" 1
# 1 "<built-in>" 3



# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "test" 2
# 1 "<built-inxxx>" 1
# 1 "templates/GenericTemplatexxx.hs" 2
{-# FOO
----

And an error occurs because of "  #-}".

So, replacing "-x c" with "-x assembler-with-cpp" in a wrapper is a
MUST. And HS files generated by alex and happy should not include
lines started with "# ".

My solution so far is adding "-optP-P" to alex and happy to not
generate line markers. An example patch to alex is attached.

I can build GHC head with GHC/clang-wrapper and with alex and happy
with this hack.

--Kazu

diff --git a/Setup.lhs b/Setup.lhs
index 302a3f0..6ab62d5 100644
--- a/Setup.lhs
+++ b/Setup.lhs
@@ -44,7 +44,7 @@ myPostBuild _ flags _ lbi = do
       runProgram p = rawSystemProgramConf verbosity p (withPrograms lbi)
       cpp_template src dst opts = do
         let tmp = dst ++ ".tmp"
-        runProgram ghcProgram (["-o", tmp, "-E", "-cpp", "templates" </> src] ++ opts)
+        runProgram ghcProgram (["-o", tmp, "-E", "-cpp", "-optP-P", "templates" </> src] ++ opts)
         writeFile dst . unlines . map mungeLinePragma . lines =<< readFile tmp
         removeFile tmp
 





Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Carter Schonwald
So did you find a bug in the current design of the clang-wrapper hack? If
so it'd be better to get it fixed there rather than in the Alex/happy setup
HS files.

On Tuesday, November 19, 2013, Kazu Yamamoto wrote:

> Hi Carter,
> SimonM, please read this message.
>
> I will answer Carter's question and show a solution of my problem.
>
> > Kazu. This is exactly the problem I linked to.  Could you try the
> proposed
> > patches to test if they allow builds to succeed with a wrapped clang on
> > your machine?
>
> I installed nkpart's alex and happy with GHC/clang-wrapper. With this
> alex and happy, I can build GHC head with GHC/GCC42. But I cannot
> build GHC head with GHC/clang-wrapper.
>
> Moreover, I can install happy and alex with GHC/clang-wrapper without
> nkpart's patches.
>
> I think that your problem is how to build alex and happy with
> GHC/clang-wrapper. But my problem is how to compile HS files created
> by alex and happy with GHC/clang-wrapper.
>
> After deep investigation, I found the source of my problem. Consider
> the following file created by CPP of clang or GCC:
>
> ----
> # 1 "<built-inxxx>" 1
> # 1 "templates/GenericTemplatexxx.hs" 2
> {-# FOO
>   #-}
> ----
>
> % clang -E -undef -x assembler-with-cpp this_file
> generates:
>
> ----
> # 1 "test"
> # 1 "<built-in>" 1
> # 1 "test" 2
>  # 1 "<built-inxxx>" 1
>
>  # 1 "templates/GenericTemplatexxx.hs" 2
>
> {-# FOO
>   #-}
> ----
>
> So, the line started with " #" cannot be treated by GHC. This is the
> problem.
>
> % clang -E -undef -x c this_file
> generates:
>
> ----
> # 1 "test"
> # 1 "<built-in>" 1
> # 1 "<built-in>" 3
>
>
>
> # 1 "<command line>" 1
> # 1 "<built-in>" 2
> # 1 "test" 2
> # 1 "<built-inxxx>" 1
> # 1 "templates/GenericTemplatexxx.hs" 2
> {-# FOO
> ----
>
> And an error occurs because of "  #-}".
>
> So, replacing "-x c" with "-x assembler-with-cpp" in a wrapper is a
> MUST. And HS files generated by alex and happy should not include
> lines started with "# ".
>
> My solution so far is adding "-optP-P" to alex and happy to not
> generate line markers. An example patch to alex is attached.
>
> I can build GHC head with GHC/clang-wrapper and with alex and happy
> with this hack.
>
> --Kazu
>
> diff --git a/Setup.lhs b/Setup.lhs
> index 302a3f0..6ab62d5 100644
> --- a/Setup.lhs
> +++ b/Setup.lhs
> @@ -44,7 +44,7 @@ myPostBuild _ flags _ lbi = do
>        runProgram p = rawSystemProgramConf verbosity p (withPrograms lbi)
>        cpp_template src dst opts = do
>          let tmp = dst ++ ".tmp"
> -        runProgram ghcProgram (["-o", tmp, "-E", "-cpp", "templates" </>
> src] ++ opts)
> +        runProgram ghcProgram (["-o", tmp, "-E", "-cpp", "-optP-P",
> "templates" </> src] ++ opts)
>          writeFile dst . unlines . map mungeLinePragma . lines =<<
> readFile tmp
>          removeFile tmp
>
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <javascript:;>
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131119/5a5d4553/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Kazu Yamamoto (山本和彦)
> So did you find a bug in the current design of the clang-wrapper hack?

No. What I found is that the current design of the clang-wrapper hack
is appropriate.

"-x assembler-with-cpp" is necessary to rescue
----
{-# RULE whatever
  #-}
---

> If so it'd be better to get it fixed there rather than in the
> Alex/happy setup HS files.

If we can do this, it's very good. But this is not good enough.
happy/alex hack are also necessary to not generate
----
 # 1 "<built-inxxx>" 1

 # 1 "templates/GenericTemplatexxx.hs" 2
----

--Kazu

Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Carter Schonwald
so what are you proposing? Are you agreeing that those patches work with
clang wrapper, but also remarking that its unfortunate that such a hack is
needed?




On Tue, Nov 19, 2013 at 4:52 PM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:

> > So did you find a bug in the current design of the clang-wrapper hack?
>
> No. What I found is that the current design of the clang-wrapper hack
> is appropriate.
>
> "-x assembler-with-cpp" is necessary to rescue
> ----
> {-# RULE whatever
>   #-}
> ---
>
> > If so it'd be better to get it fixed there rather than in the
> > Alex/happy setup HS files.
>
> If we can do this, it's very good. But this is not good enough.
> happy/alex hack are also necessary to not generate
> ----
>  # 1 "<built-inxxx>" 1
>
>  # 1 "templates/GenericTemplatexxx.hs" 2
> ----
>
> --Kazu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131119/a2673a70/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Kazu Yamamoto (山本和彦)
Hi,

> so what are you proposing?

I'm not proposing anything. I just want to share information so that
we can find a good solution.

> Are you agreeing that those patches work with clang wrapper, but
> also remarking that its unfortunate that such a hack is needed?

As I said, nkpart's patches are not necessary in my environment. But
they do not side-effect, so it is fine with me to apply these patches.

--Kazu

Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Kazu Yamamoto (山本和彦)
In reply to this post by Kazu Yamamoto (山本和彦)
Hi,

> No. What I found is that the current design of the clang-wrapper hack
> is appropriate.
>
> "-x assembler-with-cpp" is necessary to rescue
> ----
> {-# RULE whatever
>   #-}
> ---

I read the source of clang. The argument of "-x" is defined in
lib/Frontend/CompilerInvocation.cpp:

      .Case("c", IK_C)
      .Case("cl", IK_OpenCL)
      .Case("cuda", IK_CUDA)
      .Case("c++", IK_CXX)
      .Case("objective-c", IK_ObjC)
      .Case("objective-c++", IK_ObjCXX)
      .Case("cpp-output", IK_PreprocessedC)
      .Case("assembler-with-cpp", IK_Asm)
      .Case("c++-cpp-output", IK_PreprocessedCXX)
      .Case("objective-c-cpp-output", IK_PreprocessedObjC)
      .Case("objc-cpp-output", IK_PreprocessedObjC)
      .Case("objective-c++-cpp-output", IK_PreprocessedObjCXX)
      .Case("objc++-cpp-output", IK_PreprocessedObjCXX)
      .Case("c-header", IK_C)
      .Case("cl-header", IK_OpenCL)
      .Case("objective-c-header", IK_ObjC)
      .Case("c++-header", IK_CXX)
      .Case("objective-c++-header", IK_ObjCXX)
      .Cases("ast", "pcm", IK_AST)
      .Case("ir", IK_LLVM_IR)

In my experiment, no argument except "assembler-with-cpp" can rescue
"  #-}".

--Kazu


Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Carter Schonwald
Yes.  So we agree.

 Clang only works with ghc when passed that flag.  Hence for building ghc,
clang should only be called via a wrapper script if the host ghc is 7.6 or
older.

The whole point of the clang wrapper script is to pass that flag.

Nicks patch to Alex and happy is to address a further quirk of clang cpp.

Was there an issue if you used a wrapped clang and those patches or not?
I'm really confused.

Cheers

-carter


On Tuesday, November 19, 2013, Kazu Yamamoto wrote:

> Hi,
>
> > No. What I found is that the current design of the clang-wrapper hack
> > is appropriate.
> >
> > "-x assembler-with-cpp" is necessary to rescue
> > ----
> > {-# RULE whatever
> >   #-}
> > ---
>
> I read the source of clang. The argument of "-x" is defined in
> lib/Frontend/CompilerInvocation.cpp:
>
>       .Case("c", IK_C)
>       .Case("cl", IK_OpenCL)
>       .Case("cuda", IK_CUDA)
>       .Case("c++", IK_CXX)
>       .Case("objective-c", IK_ObjC)
>       .Case("objective-c++", IK_ObjCXX)
>       .Case("cpp-output", IK_PreprocessedC)
>       .Case("assembler-with-cpp", IK_Asm)
>       .Case("c++-cpp-output", IK_PreprocessedCXX)
>       .Case("objective-c-cpp-output", IK_PreprocessedObjC)
>       .Case("objc-cpp-output", IK_PreprocessedObjC)
>       .Case("objective-c++-cpp-output", IK_PreprocessedObjCXX)
>       .Case("objc++-cpp-output", IK_PreprocessedObjCXX)
>       .Case("c-header", IK_C)
>       .Case("cl-header", IK_OpenCL)
>       .Case("objective-c-header", IK_ObjC)
>       .Case("c++-header", IK_CXX)
>       .Case("objective-c++-header", IK_ObjCXX)
>       .Cases("ast", "pcm", IK_AST)
>       .Case("ir", IK_LLVM_IR)
>
> In my experiment, no argument except "assembler-with-cpp" can rescue
> "  #-}".
>
> --Kazu
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <javascript:;>
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131119/962353be/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Kazu Yamamoto (山本和彦)
> Was there an issue if you used a wrapped clang and those patches or not?
> I'm really confused.

Even with GHC/clang-wrapper and alex/happy with Nick's patches, I
cannot build GHC head. (I'm not using GCC 42 at all in this case.)

AlexTemplate (pre-processed by clang) has linemarkers like this:

----
# 1 "<built-in>"
----

So, Lexer.hs generated from Lexer.x by alex also includes this one.

Lexer.hs is CPP language extension. So, it is pre-processed again by
clang. Since clang-wrapper specifies "-x assembler-with-cpp",
generated Lexcer.hscpp contains:

----
 # 1 "<built-in>"
----

GHC cannot handle this, so build fails.

My hack lets alex and happy not to produce linemarkers at all.

Is this explanation clear to you?

P.S.

If we modify clang-wrapper to not convert "-x c" to "-x
assembler-with-cpp", some other files which contains " #-}" cannot be
compiled.

--Kazu

Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Carter Schonwald
Ok.   Got it.  So some more patches were needed.

Pardon the asking, was somehow getting confused earlier.

On Tuesday, November 19, 2013, Kazu Yamamoto wrote:

> > Was there an issue if you used a wrapped clang and those patches or not?
> > I'm really confused.
>
> Even with GHC/clang-wrapper and alex/happy with Nick's patches, I
> cannot build GHC head. (I'm not using GCC 42 at all in this case.)
>
> AlexTemplate (pre-processed by clang) has linemarkers like this:
>
> ----
> # 1 "<built-in>"
> ----
>
> So, Lexer.hs generated from Lexer.x by alex also includes this one.
>
> Lexer.hs is CPP language extension. So, it is pre-processed again by
> clang. Since clang-wrapper specifies "-x assembler-with-cpp",
> generated Lexcer.hscpp contains:
>
> ----
>  # 1 "<built-in>"
> ----
>
> GHC cannot handle this, so build fails.
>
> My hack lets alex and happy not to produce linemarkers at all.
>
> Is this explanation clear to you?
>
> P.S.
>
> If we modify clang-wrapper to not convert "-x c" to "-x
> assembler-with-cpp", some other files which contains " #-}" cannot be
> compiled.
>
> --Kazu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131120/518fd2b0/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Kazu Yamamoto (山本和彦)
> Ok.   Got it.  So some more patches were needed.

Nice.

> Pardon the asking, was somehow getting confused earlier.

No problem. Maybe I explained too quickly.

--Kazu

Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Nick Partridge
I think these are difficult problems to talk about, because there are so
many different versions of things flying about. But if I can sum up what I
think has gone on here, I want to make sure we know what needs to happen
next:

* Kazu has verified that my patches to happy/alex allow us to build HEAD
using GHC 7.6 + GCC 4.8.

* There are separate patches needed for happy/alex to allow building of
HEAD using GHC 7.6 + Clang (and as I see in the other thread, also a patch
for ghc.mk)

Kazu, can you put create pull requests for happy and alex with your
required changes?

If those changes play nice, hopefully we can then ship new versions of
happy and alex for mac users shortly.

- Nick





On Wed, Nov 20, 2013 at 3:25 PM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:

> > Ok.   Got it.  So some more patches were needed.
>
> Nice.
>
> > Pardon the asking, was somehow getting confused earlier.
>
> No problem. Maybe I explained too quickly.
>
> --Kazu
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131121/3a7ae19a/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Kazu Yamamoto (山本和彦)
Hi,

> Kazu, can you put create pull requests for happy and alex with your
> required changes?

I have one concern.

The version of alex on Hackage is 3.1.2. But that of github is
3.1.1:

        https://github.com/simonmar/alex/blob/master/alex.cabal

# This inconsistency exists in happy, too.

Did SimonM forget to push his local changes?

Should I send pull requests on github, anyway?

--Kazu

Reply | Threaded
Open this post in threaded view
|

Building GHC head with clang on Mavericks

Nick Partridge
I think he has forgotten, yes. But yeah do send the pull requests anyway,
my last set got merged in. The missing code seems to just be the version
bump and a new test case:
http://hdiff.luite.com/cgit/alex/commit/?id=f0f1f332d56b3fd21930d771b15b7c0d92ffbe7b



On Thu, Nov 21, 2013 at 3:25 PM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:

> Hi,
>
> > Kazu, can you put create pull requests for happy and alex with your
> > required changes?
>
> I have one concern.
>
> The version of alex on Hackage is 3.1.2. But that of github is
> 3.1.1:
>
>         https://github.com/simonmar/alex/blob/master/alex.cabal
>
> # This inconsistency exists in happy, too.
>
> Did SimonM forget to push his local changes?
>
> Should I send pull requests on github, anyway?
>
> --Kazu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131121/d2a10897/attachment-0001.html>

12