Re: GHC arm64 porting
On Tue, Apr 01, 2014 at 02:49:51PM +0200, Joachim Breitner wrote:
> Am Dienstag, den 01.04.2014, 13:16 +0100 schrieb Colin Watson:
> > I've attached the arm64-specific parts of the current patch I'm working
> > with, most of which are due to Karel Gardas. Assuming that I actually
> > manage to build 7.6 (which is by no means a given), would it be
> > acceptable to apply something like this patch set to the Debian
> > packaging?
>
> Sure! Just let us know when you actually want it to be included.
Right, thanks. Continuing the saga here:
http://www.haskell.org/pipermail/haskell-cafe/2014-April/113408.html
> BTW, do you feel responsible for the existing armel architectures as
> well? These are failing in GHC 7.8:
> https://buildd.debian.org/status/package.php?p=ghc&suite=experimental
Well, this is new to me, but it looks like this patch would do it for
armhf:
diff --git a/compiler/typecheck/TcSplice.lhs-boot b/compiler/typecheck/TcSplice.lhs-boot
index c496aed..6cd8183 100644
--- a/compiler/typecheck/TcSplice.lhs-boot
+++ b/compiler/typecheck/TcSplice.lhs-boot
@@ -26,7 +26,9 @@ tcTypedBracket :: HsBracket Name
-> TcRhoType
-> TcM (HsExpr TcId)
+#ifdef GHCI
tcTopSpliceExpr :: Bool -> TcM (LHsExpr Id) -> TcM (LHsExpr Id)
+#endif
runQuasiQuoteDecl :: HsQuasiQuote RdrName -> TcM [LHsDecl RdrName]
runQuasiQuoteExpr :: HsQuasiQuote RdrName -> TcM (LHsExpr RdrName)
@@ -34,12 +36,12 @@ runQuasiQuoteType :: HsQuasiQuote RdrName -> TcM (LHsType RdrName)
runQuasiQuotePat :: HsQuasiQuote RdrName -> TcM (LPat RdrName)
runAnnotation :: CoreAnnTarget -> LHsExpr Name -> TcM Annotation
+#ifdef GHCI
runMetaE :: LHsExpr Id -> TcM (LHsExpr RdrName)
runMetaP :: LHsExpr Id -> TcM (LPat RdrName)
runMetaT :: LHsExpr Id -> TcM (LHsType RdrName)
runMetaD :: LHsExpr Id -> TcM [LHsDecl RdrName]
-#ifdef GHCI
lookupThName_maybe :: TH.Name -> TcM (Maybe Name)
runQuasi :: TH.Q a -> TcM a
#endif
I'm running a build test on harris; if that works then I'll send it
upstream and push it to darcs.
armel (which for the record I only care about in the sort of abstract
way that I care about all architectures working) is a different matter.
compiler/cbits/genSym.c is a new file in 7.8, and it uses atomic_inc.
armel is our only architecture where the implementation of atomic_inc
isn't entirely inline. I'm not sure of the proper fix, though; I
suppose the compiler could link against libHSrts (maybe only when
needed) but I have no idea whether that's reasonable. I've filed an
upstream bug:
https://ghc.haskell.org/trac/ghc/ticket/8951
--
Colin Watson [cjwatson@debian.org]
Reply to: