[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:


> 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

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

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:


Colin Watson                                       [cjwatson@debian.org]

Reply to: