April 2015 - ghc-tickets

[GHC] #10228: Increased memory usage with GHC 7.10.1
by GHC 18 May '15

18 May '15

#10228: Increased memory usage with GHC 7.10.1 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- (Repost from ghc-devs) I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed installations of GHC and this means I had to rebuild Agda and Idris because the binaries built with GHC 7.8.4 were stored inside deactivated 7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due to GHC taking up all of available memory. With Idris the problematic module was Idris.ElabTerm (~2900LOC). The interesting part of the story is that when I do a clean build of Idris GHC consumes all of memory when compiling that module and I have to kill the build. But when I restart the build after killing GHC the module is compiled using a reasonable amount of memory and within reasonable time. With Agda the problematic module is Agda.TypeChecking.Serialise (~2000LOC). The trick with killing the build and restarting it didn't work in this case. I had to compile Agda with GHC 7.8.4 (which works without problems though the mentioned module still requires a lot of memory) and alter my setup so that Agda binary is not stored inside GHC sandbox. I wonder if any of you came across similar issues with GHC 7.10.1? Do we have any performance data that allows to compare memory usage and performance of GHC 7.10.1 with previous stable releases? All of the above happened on 64bit Debian Wheezy with 2GB of RAM. On my second machine, this time with 4GB of RAM, compiling Agda ran out of memory (again Agda.TypeChecking.Serialise module) and I had to kill the build. But once I restarted the build the module was compiled succesfully in a matter of minutes and using around 50% of memory. This looks like some kind of memory leak in GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10228> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10293: CallArity taking 20% of compile time
by GHC 14 May '15

14 May '15

#10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `CallArity` analysis can, apparently, take 20% of compile time. That's a lot for one analysis that is on by default with `-O`. Michael Terepeta writes: Out of curiosity I had a look at compiling haskell-src-exts since that takes quite a while. I've used ghc HEAD and 7.8.4 (both built with BuildFlavour=prof & bootstrapped with a standard ghc 7.8.4) and it's interesting -- the current HEAD takes quite a bit longer and allocates way more than 7.8.4. One of the main things that stand out is the CallArity analysis (which IIRC was not there in 7.8.4). So unless I messed something up with measuring, the analysis seem to be pretty expensive. HEAD {{{ Sun Apr 12 15:52 2015 Time and Allocation Profiling Report (Final) ghc +RTS -p -RTS [...] total time = 147.84 secs (147841 ticks @ 1000 us, 1 processor) total alloc = 172,378,600,408 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc SimplTopBinds SimplCore 32.4 28.8 CallArity SimplCore 18.4 25.6 lintAnnots CoreLint 4.5 4.6 CoreTidy HscMain 4.5 5.1 pprNativeCode AsmCodeGen 3.2 3.4 OccAnal SimplCore 3.2 3.1 occAnalBind.assoc OccurAnal 2.6 2.5 StgCmm HscMain 2.3 1.9 Simplify SimplCore 2.1 0.2 RegAlloc AsmCodeGen 2.1 2.4 FloatOutwards SimplCore 2.0 1.6 regLiveness AsmCodeGen 1.9 1.9 tc_rn_src_decls TcRnDriver 1.8 1.3 sink CmmPipeline 1.7 1.5 NewStranal SimplCore 1.3 1.5 genMachCode AsmCodeGen 1.1 1.0 layoutStack CmmPipeline 1.0 1.0 }}} HEAD with `-fno-call-arity` {{{ Sun Apr 12 18:16 2015 Time and Allocation Profiling Report (Final) ghc +RTS -p -RTS [...] -fno-call-arity total time = 113.71 secs (113714 ticks @ 1000 us, 1 processor) total alloc = 121,884,896,720 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc SimplTopBinds SimplCore 37.2 36.6 CoreTidy HscMain 6.0 7.3 lintAnnots CoreLint 5.8 6.5 pprNativeCode AsmCodeGen 4.1 4.8 OccAnal SimplCore 3.6 3.8 occAnalBind.assoc OccurAnal 2.9 3.2 StgCmm HscMain 2.9 2.6 RegAlloc AsmCodeGen 2.6 3.4 FloatOutwards SimplCore 2.6 2.3 regLiveness AsmCodeGen 2.5 2.8 tc_rn_src_decls TcRnDriver 2.4 1.9 Simplify SimplCore 2.4 0.3 sink CmmPipeline 2.1 2.2 NewStranal SimplCore 1.7 2.1 genMachCode AsmCodeGen 1.4 1.4 layoutStack CmmPipeline 1.4 1.4 NativeCodeGen CodeOutput 1.1 1.2 FloatInwards SimplCore 1.1 1.4 do_block Hoopl.Dataflow 1.0 0.6 Digraph.scc Digraph 0.8 1.3 }}} GHC 7.8.4 {{{ Sun Apr 12 15:41 2015 Time and Allocation Profiling Report (Final) ghc +RTS -p -RTS [...] total time = 93.11 secs (93112 ticks @ 1000 us, 1 processor) total alloc = 103,135,975,120 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc SimplTopBinds SimplCore 38.5 37.4 pprNativeCode AsmCodeGen 6.2 7.2 StgCmm HscMain 3.9 4.2 RegAlloc AsmCodeGen 3.7 5.1 occAnalBind.assoc OccurAnal 3.3 3.6 OccAnal SimplCore 3.3 3.6 regLiveness AsmCodeGen 3.1 3.4 FloatOutwards SimplCore 2.9 2.4 sink CmmPipeline 2.8 2.8 Simplify SimplCore 2.6 0.3 tc_rn_src_decls TcRnDriver 2.4 2.1 genMachCode AsmCodeGen 1.9 2.0 NewStranal SimplCore 1.8 2.1 layoutStack CmmPipeline 1.8 1.8 Core2Core HscMain 1.3 1.2 deSugar HscMain 1.1 1.1 do_block Hoopl.Dataflow 1.1 0.7 CoreTidy HscMain 1.0 1.1 CorePrep HscMain 1.0 1.1 Digraph.scc Digraph 0.9 1.5 versioninfo MkIface 0.9 1.0 zonkEvBndr_zonkTcTypeToType TcHsSyn 0.6 1.4 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10293> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP'
by GHC 13 May '15

13 May '15

#8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP' ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Looks like WITHSMP is not generated anywere, thus don't know how it worked before. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8789> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10177: Typeable solver regression
by GHC 13 May '15

13 May '15

#10177: Typeable solver regression -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This bug is known and fixed in master. Simon and Austin and Iavor are all aware of it. This ticket exists to ensure that the fix doesn't get lost. This code breaks under the Typeable solver in 7.10.1-rc3 and is fixed in master. The relevant commit in master is 3a0019e3672097761e7ce09c811018f774febfd2 : Improve `Typeable` solver. {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE FlexibleContexts #-} module Bug where import Data.Typeable newtype V n a = V [a] class Typeable a => C a instance (Typeable (V n), Typeable a) => C (V n a) -- Bug.hs:13:10: -- Could not deduce (Typeable (V n a)) -- arising from the superclasses of an instance declaration -- from the context (Typeable (V n), Typeable a) -- bound by the instance declaration at Bug.hs:13:10-50 -- In the instance declaration for ‘C (V n a)’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10177> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10307: Api Annotations: RdrHsSyn.mkAtDefault causes annotations to be disconnected.
by GHC 11 May '15

11 May '15

#10307: Api Annotations: RdrHsSyn.mkAtDefault causes annotations to be disconnected. -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The code for `mkAtDefault` is as follows. {{{#!hs mkATDefault (L loc (TyFamInstDecl { tfid_eqn = L _ e })) | TyFamEqn { tfe_tycon = tc, tfe_pats = pats, tfe_rhs = rhs } <- e = do { tvs <- checkTyVars (ptext (sLit "default")) equalsDots tc (hswb_cts pats) ; return (L loc (TyFamEqn { tfe_tycon = tc , tfe_pats = tvs , tfe_rhs = rhs })) } }}} An associated type in a class of the form {{{#!hs type FoldableConstraint t x = () }}} has an `AnnEqual` attached to the location in `tfid_eqn`. Since the location is discarded, this annotation is then disconnected from the AST. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10307> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10309: ApiAnnotations : mkGadtDecl discards annotations for HsFunTy
by GHC 11 May '15

11 May '15

#10309: ApiAnnotations : mkGadtDecl discards annotations for HsFunTy -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When `mkGadtDecl` is presented wih a `HsFunTy` it discards the SrcSpan, thus disconnecting any annotations on the `HsFunTy`. {{{#!hs mkGadtDecl names (L ls (HsForAllTy imp Nothing qvars cxt tau)) = return $ mk_gadt_con names where (details, res_ty) -- See Note [Sorting out the result type] = case tau of L _ (HsFunTy (L l (HsRecTy flds)) res_ty) -> (RecCon (L l flds), res_ty) _other -> (PrefixCon [], tau) ... }}} This can be triggered by the following {{{#!hs {-# LANGUAGE GADTs #-} module GADTRecords2 (H1(..)) where -- | h1 data H1 a b where C3 :: (Num a) => { field :: a -- ^ hello docs } -> H1 Int Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10309> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10287: ApiAnnotations : BooleanFormula construction discards original
by GHC 11 May '15

11 May '15

#10287: ApiAnnotations : BooleanFormula construction discards original -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The MINIMAL pragma is captured in the parser using a `BooleanFormula`. The constructors (`mkBool`,`mkAnd`,`mkOr`) are smart and try to minimise the boolean formula as it is constructed. This discards the original information, making round tripping impossible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10287> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10357: ApiAnnotations : pquals production adds AnnVbar in the wrong place
by GHC 11 May '15

11 May '15

#10357: ApiAnnotations : pquals production adds AnnVbar in the wrong place -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `Parser.y` production for `pquals` is {{{ pquals :: { Located [[LStmt RdrName (LHsExpr RdrName)]] } : squals '|' pquals {% addAnnotation (gl $ last $ unLoc $1) AnnVbar (gl $2) >> return (sLL $1 $> (reverse (unLoc $1) : unLoc $3)) } | squals { L (getLoc $1) [reverse (unLoc $1)] } }}} The `squals` are returned in reverse order, so the `AnnVbar` should be attached to the `head` of the list, not the `last`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10357> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10358: ApiAnnotations : PatBind gives wrong SrcSpan for the pattern.
by GHC 11 May '15

11 May '15

#10358: ApiAnnotations : PatBind gives wrong SrcSpan for the pattern. -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The production for `decl_no_th` starts {{{ decl_no_th :: { Located (OrdList (LHsDecl RdrName)) } : sigdecl { $1 } | '!' aexp rhs {% do { let { e = sLL $1 $> (SectionR (sL1 $1 (HsVar bang_RDR)) $2) }; pat <- checkPattern empty e; ... }}} The `e` value should be just the pattern, excluding the `rhs`, but the span created includes the `rhs`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10358> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries"
by GHC 11 May '15

11 May '15

#10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries" -------------------------------------+------------------------------------- Reporter: pgj | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: | Version: 7.10.1-rc1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This was originally spotted and [https://mail.haskell.org/pipermail/ghc- devs/2015-February/008407.html posted to the ghc-devs mailing list] by Joachmin Breitner, but apparently since nobody has submitted a ticket for this relatively serious issue, here it is. I am quoting Joachim: {{{ while the index at http://haskell.inf.elte.hu/docs/7.11.20150222.noWin32/html/libraries/index.… exists, navigating to http://haskell.inf.elte.hu/docs/7.11.20150222.noWin32/html/libraries/Data- Char.html yields a 404 error. Same for http://haskell.inf.elte.hu/docs/latest/html/libraries/Data-Char.html }}} And [https://mail.haskell.org/pipermail/ghc-devs/2015-February/008408.html I have replied] the following to his initial email (I am involved in this because I am doing daily snapshots of the documentation through my FreeBSD GHC builders): {{{ Yes, I can confirm this bug. For what it is worth, the files are all there, the link appears to be broken: it is missing the subdirectory with the name of the package. That is, the proper link should be something like that: http://haskell.inf.elte.hu/docs/7.9.20141222.noWin32/html/libraries/base-4.… /Data-Char.html (Note the missing "base-4.8.0.0".) I have checked this with GHC 7.8.3, and everything is right there, while this problem seems to appear with GHC 7.10 RC2 and GHC-HEAD (starting from somewhere between mid-September and November -- that is what a quick bisecting tells me). }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10206> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5