- ghc-devs - Haskell.org

ghc 7.8.2: Reachable modules from DynFlags out of date
by Peter Trommler 10 Jun '14

10 Jun '14

Hi, Preparing ghc for the upcoming Haskell Platform 2014.2 on openSUSE I came across the following issue on PowerPC 64 bit: > [ 6023s] inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" > [ 6025s] Reachable modules from DynFlags out of date > [ 6025s] Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) > [ 6025s] Redundant modules: Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 FastBool Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream > [ 6025s] make[1]: *** [compiler/stage2/dll-split.stamp] Error 1 My build.mk contains the following: > GhcUnregisterised=YES > GhcWithNativeCodeGen=NO > GhcWithInterpreter=NO > SplitObjs=NO > SRC_HC_OPTS+= -optc-mminimal-toc -optc-fno-builtin > SRC_CC_OPTS+= -mminimal-toc -fno-builtin I need the last two lines to: 1. have the build get that far (something is overflowing the TOC on powerpc64) 2. to get rid of loads of gcc warnings about built-in mem* functions What do I need to do to „fix compiler/ghc.mk“ (see line 3 of my build log excerpt)? Thanks! Peter

1 0

Re: [commit: ghc] ghc-7.8: Release notes (32b4bf3)
by Herbert Valerio Riedel 10 Jun '14

10 Jun '14

On 2014-06-09 at 18:08:20 +0200, git-4Dsf34iY/NkouOHNgZ69ag(a)public.gmane.org wrote: [...] > + <listitem> > + <para> > + The libraries <literal>haskeline</literal>, > + <literal>xhtml</literal>, <literal>terminfo</literal>, > + <literal>transformers</literal>, and > + <literal>haskeline</literal> are now exported and > + registered in the package database. They previously > + shipped with GHC but were not registered, leading to > + errors where shared objects could be overwritten. (issue > + #8919). > + </para> > + </listitem> Just a minor nit-pick: Afaik, 'transformers' *was* properly exported & registered in 7.8.[12]. It just wasn't mentioned in the release notes for 7.8.[12] IIRC.

1 0

Failed to load interface for GHC.Integer.Type
by Joachim Breitner 10 Jun '14

10 Jun '14

Hi, since http://git.haskell.org/ghc.git/commitdiff/1946922c61df427e59f8a00572fd4dd65… travis is complaining: HC [stage 1] libraries/base/dist-install/build/GHC/Unicode.o-boot HC [stage 1] libraries/base/dist-install/build/Data/Coerce.o HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Debug.o Top level: Failed to load interface for â€˜GHC.Integer.Typeâ€™ There are files missing in the â€˜integer-gmpâ€™ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. make[1]: *** [libraries/base/dist-install/build/Data/Coerce.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 Does anyone have an idea what may be causing this? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

3 6

Adding atomic primops
by Johan Tibell 09 Jun '14

09 Jun '14

Hi, I found myself needing atomic operations on basic, mutable numeric values. I wrote a short design doc that I'd like feedback on: https://ghc.haskell.org/trac/ghc/wiki/AtomicPrimops I will try to implement these for 7.10. -- Johan

7 22

[PATCH] Fix -unawareness of large-addresses on mingw (#8520)
by transfuturist 08 Jun '14

08 Jun '14

--- compiler/main/SysTools.lhs | 1 + 1 file changed, 1 insertion(+) diff --git a/compiler/main/SysTools.lhs b/compiler/main/SysTools.lhs index dc9642d..1cf1155 100644 --- a/compiler/main/SysTools.lhs +++ b/compiler/main/SysTools.lhs @@ -740,6 +740,7 @@ getLinkerInfo' dflags = do [ -- Reduce ld memory usage "-Wl,--hash-size=31" , "-Wl,--reduce-memory-overheads" + , "-Wl,--large-address-aware" --Trac #8520 -- Increase default stack, see -- Note [Windows stack usage] , "-Xlinker", "--stack=0x800000,0x800000" ] -- 1.8.4.msysgit.0

3 4

Re: GHC/cabal release procedures, and Stackage
by Joachim Breitner 08 Jun '14

08 Jun '14

Hi, Am Sonntag, den 08.06.2014, 07:55 +0300 schrieb Michael Snoyman: > > Actually, GHC HEAD isn't the problem I'm running into right now. I'm > already testing that[1] using Herbert's Ubuntu PPA[2] Ah, cool! > I'm specifically looking for builds off of the 7.8 branch so I can > start testing point releases. Then I guess the easiest would be if Herbert would add that to his PPA. > [2] And in case anyone's curious, restrictive upper bounds on > transformers and template-haskell are preventing a build right now. Hmm, it would be nice if cabal had a “best effort” mode where when some of the requested packages cannot be built it at least builds the rest. Also, isn’t there a new flag to cabal to selectively ignore upper bounds? (I can’t find the documentation for the latest cabal-install online right now.) Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 1

Re: [GHC] #8226: Remove the old style -- # Haddock comments.
by Alfredo Di Napoli 07 Jun '14

07 Jun '14

Thanks Fuuzetsu, Tomorrow I'll still be at the ZuriHac, so hopefully I'll able to adjust the patch :) I'll poke you if you'll be around Thanks! Alfredo Di Napoli > On 07/giu/2014, at 07:23, "GHC" <ghc-devs(a)haskell.org> wrote: > > #8226: Remove the old style -- # Haddock comments. > -------------------------------------+------------------------------------ > Reporter: Fuuzetsu | Owner: > Type: task | Status: patch > Priority: normal | Milestone: 7.10.1 > Component: Compiler | Version: 7.7 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: Unknown/Multiple > Type of failure: None/Unknown | Difficulty: Unknown > Test Case: | Blocked By: > Blocking: | Related Tickets: > -------------------------------------+------------------------------------ > > Comment (by Fuuzetsu): > > Sorry I fell behind a bit on reading GHC tickets. > > Yes adinapoli, those should also be removed, we do not use --# for > anything and it served the same purpose as {-# as far as I know. > > Also the data type used to store that type of comment should be removed: > > https://github.com/ghc/ghc/blob/master/compiler/parser/Lexer.x#L625 > > FTR the Haddock ticket is now tracked at > https://github.com/haskell/haddock/issues/171 > > Thanks for looking into this, feel free to poke me on IRC/e-mail if you > need more immediate review. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8226#comment:5> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler

1 0

7.8.3 release - please speak up soon.
by Austin Seipp 07 Jun '14

07 Jun '14

Hello all, I'm going to do the 7.8.3 release very soon. Now is the time to speak up if something should go in. Here's the take away from this: I *am not* going to fix any other bugs for 7.8.3 or close any other tickets than the following: - #9155 https://ghc.haskell.org/trac/ghc/ticket/9155 - #7241 https://ghc.haskell.org/trac/ghc/ticket/7241 - #8683 https://ghc.haskell.org/trac/ghc/ticket/8683 - #8935 https://ghc.haskell.org/trac/ghc/ticket/8935 - #9080 https://ghc.haskell.org/trac/ghc/ticket/9080 The first one is a bug fix from Simon for the code generator. The remaining ones are patches I intend to land today. So here's the deal: if you don't speak up now, you'll have to wait until 7.8.4 (sometime in the late summer I imagine) to get your word in. Is there anything anyone absolutely must have that I've missed? Full details on what was fixed are on this page - the 'infoneeded' and 'new' tickets will be punted to a new milestone shortly. All 'closed' tickets are merged and in the 7.8 branch already: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.3 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 5

Re: Offering GHC builder build slaves
by Páli Gábor János 07 Jun '14

07 Jun '14

2014-04-09 0:25 GMT+02:00 Lyndon Nerenberg <lyndon(a)orthanc.ca>: > Is there any way to verify that builder-client can actually do a successful build, > without having access to the build system server? 'builder-client --do-build' > wants to connect and authenticate first; it would be helpful if there was a way > to bypass that so that I can first verify the local build environment is sane. This is because the builder client gets the commands to be executed from the server. A naive solution would be to put the commands in the script and run it. You can find the current set of installed commands at one of the active builders page, e.g. [1]. Note that you may have to change some of them, such as the flags passed to configure script and name of the make(1) command. [1] http://haskell.inf.elte.hu/builders/solaris-x86-head/23.html

3 3

RE: GHC/cabal release procedures, and Stackage
by Simon Peyton Jones 06 Jun '14

06 Jun '14

Michael I think that would be great. Absolutely: the earlier we can catch regressions the better. Couldn’t we make it part of the continuous-integration builds (Travis?) that various folk are running, eg. Joachim? I’m hazy about how all of this works, but I’d love it just to happen automatically every night or whatever, with failure being reported by email, with instructions on how to reproduce the failure. Might you work with Joachim and others to make that possible? Thanks for suggesting it Simon From: Michael Snoyman [mailto:michael@fpcomplete.com] Sent: 05 June 2014 17:10 To: Simon Peyton Jones Subject: GHC/cabal release procedures, and Stackage Hi Simon, I wanted to bring up an idea I've been playing with for a few weeks now. The past few releases of GHC and cabal-install have introduced regressions that were not caught by test suites, but were caught by building code from Hackage. In particular, I discovered some of these bugs almost immediately after release by doing normal Stackage builds. So I'd like to propose that part of the GHC and cabal-install release processes include trying to run a build of Stackage. This should be both a good stress test, plus- since Stackage covers the majority of actively used packages- should also be a good indication that early adopters of the new version won't immediately hit bugs. I'm happy to volunteer to be a part of this process (e.g., to be the guy who actually runs the builds). As a user, I'd definitely appreciate the opportunity to iron out bugs before they hit the light of day and start causing larger headaches. What do you think? Thanks, Michael PS: A relevant issue is an upcoming yesod-bin breakage in GHC 7.8.3: https://github.com/yesodweb/yesod/issues/748. I haven't been able to investigate this myself since there seems to be a build bug for 7.8.3 when using the Gold linker.

2 1