February 2018 - ghc-tickets

[GHC] #13962: GHCi allows unsaturated type family
by GHC 08 Jan '19

08 Jan '19

#13962: GHCi allows unsaturated type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Taken from [http://ics.p.lodz.pl/~stolarek/_media/pl:research:promotion- haskell14-slides.pdf Promoting Functions to Type Families in Haskell] {{{#!hs {-# Language TypeFamilies, PolyKinds, DataKinds, TypeOperators #-} type family Map (f :: a -> b) (xs :: [a]) :: [b] where Map f '[] = '[] Map f (x ': xs) = f x ': Map f xs data N = O | S N type family Pred (n :: N) :: N where Pred O = O Pred (S n) = n -- The type family ‘Map’ should have 2 arguments, but has been given 1 type MapPred = Map Pred }}} fails as expected, but it works in GHCi {{{ ghci> :kind Map Pred Map Pred :: [N] -> [N] ghci> :kind! Map Pred '[S (S O), S O, O] Map Pred '[S (S O), S O, O] :: [N] = '['S 'O, 'O, 'O] }}} I can only test this in GHC 7.8, 8 now. I know GHCi has weird rules for unsaturated type families but I figured I'd write a ticket because the slides say "But it is invalid to write: `Map Pred '[O, S O]`". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13962> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14677: Code generator does not correctly tag a pointer
by GHC 08 Jan '19

08 Jan '19

#14677: Code generator does not correctly tag a pointer -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{ data T a = MkT ![a] }}} The pointer stored in a `MkT` constructor should always be correctly tagged, never tagged with un-evaluated 00. C.f. [wiki:Commentary/Rts/HaskellExecution/PointerTagging] But this invariant is broken. Example taken from #14626, comment:37-39. Trac14626_1.hs {{{ module Trac14626_1 where data Style = UserStyle Int | PprDebug data SDC = SDC !Style !Int defaultUserStyle :: Bool -> Style defaultUserStyle True = UserStyle 123 defaultUserStyle False = PprDebug }}} Trac14626_2.hs {{{ module Trac14626_2 where import Trac14626_1 f :: Int -> SDC f x = SDC (defaultUserStyle (x > 1)) x }}} Compiling with `ghc Trac14626_1 Trac14626_2 -ddump-simpl -O` results in a similar scenario than the one described by Heisenbug: {{{ -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} defaultUserStyle2 defaultUserStyle2 = I# 123# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} defaultUserStyle1 defaultUserStyle1 = UserStyle defaultUserStyle2 -- RHS size: {terms: 7, types: 2, coercions: 0, joins: 0/0} defaultUserStyle defaultUserStyle = \ ds_dZ7 -> case ds_dZ7 of { False -> PprDebug; True -> defaultUserStyle1 } }}} Our `UserStyle 123` constant has been lifted to top-level, just like in Heisenbugs example. Now looking at the Core of `f` {{{ f f = \ x_a1dk -> case x_a1dk of { I# x1_a2gV -> case ># x1_a2gV 1# of { __DEFAULT -> SDC PprDebug x1_a2gV; 1# -> SDC defaultUserStyle1 x1_a2gV } } }}} (Note how `f` doesn't scrutinise defaultUserStyle1) Looking at the CMM for `f` we can see {{{ ... if (%MO_S_Le_W64(_s2hT::I64, 1)) goto c2ip; else goto c2is; c2ip: I64[Hp - 16] = SDC_con_info; P64[Hp - 8] = PprDebug_closure+2; I64[Hp] = _s2hT::I64; R1 = Hp - 15; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; c2is: I64[Hp - 16] = SDC_con_info; P64[Hp - 8] = defaultUserStyle1_closure; -- defaultUserStyle1 isn't tagged! I64[Hp] = _s2hT::I64; R1 = Hp - 15; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; }}} When generating code for f the code generator wants to know the `LambdaFormInfo` (the closure type) of `defaultUserStyle1`. Since `defaultUserStyle1` is defined in another module we end up calling `mkLFImported` in `StgCmmClosure` which ultimatively gives an `LFUnknown` which always gets a `DynTag` 0 from `lfDynTag`. I think we lack a bit of information here to give defaultUserStyle1 the correct `LFCon` lambda form. Maybe top-level binders should know its `LambdaForm` and include them in their interfaces. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14677> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1
by GHC 08 Jan '19

08 Jan '19

#13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple ConstraintKinds, KindSignatures | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The attached module compiles without errors with GHC 8.0.1 but needs an explicit kind signature with GHC 8.2.1-rc2. Mentioned in this [https://mail.haskell.org/pipermail/ghc- devs/2017-May/014222.html ghc-dev thread]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11621: GHC doesn't see () as a Constraint in type family
by GHC 08 Jan '19

08 Jan '19

#11621: GHC doesn't see () as a Constraint in type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DataKinds, TypeOperators, KindSignatures, MultiParamTypeClasses, TypeFamilies #-} import Data.Kind class NotFound type family F b where F 'False = (NotFound :: Constraint) F 'True = (() :: Constraint) }}} works fine. Removing all constraints and final line it works without any annotations and infers the type of `F :: Bool -> Constraint`: {{{#!hs type family F b where F 'False = NotFound }}} GHC seems determined that `() :: Type` unless explicitly told otherwise, I would like to be able to write: {{{#!hs type family F b where F 'False = NotFound F 'True = () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11621> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14331: Overzealous free-floating kind check causes deriving clause to be rejected
by GHC 07 Jan '19

07 Jan '19

#14331: Overzealous free-floating kind check causes deriving clause to be rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: deriving | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC rejects this program: {{{#!hs {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE PolyKinds #-} module Bug where class C a b data D = D deriving (C (a :: k)) }}} {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:8:1: error: Kind variable ‘k’ is implicitly bound in datatype ‘D’, but does not appear as the kind of any of its type variables. Perhaps you meant to bind it (with TypeInType) explicitly somewhere? | 8 | data D = D deriving (C (a :: k)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} But it really shouldn't, since it's quite possible to write the code that is should generate: {{{#!hs instance C (a :: k) D }}} Curiously, this does not appear to happen for data family instances, as this typechecks: {{{#!hs {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where class C a b data family D1 data instance D1 = D1 deriving (C (a :: k)) class E where data D2 instance E where data D2 = D2 deriving (C (a :: k)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14331> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 64

[GHC] #8326: Place heap checks common in case alternatives before the case
by GHC 07 Jan '19

07 Jan '19

#8326: Place heap checks common in case alternatives before the case ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | ------------------------------------+------------------------------------- We would like to have functions that check whether an `Int#` is a valid tag to represent `Bool` (see Note [Optimizing isTrue#] in ghc-prim): {{{ isTrue# :: Int# -> Bool isTrue# 1# = True isTrue# _ = False isFalse# :: Int# -> Bool isFalse# 0# = True isFalse# _ = False }}} We could use them with comparison primops like this: {{{ f :: Int# -> Int f x | isTrue# (x ># 0#) = I# x | otherwise = -(I# x) }}} `isTrue#` is optimized away at the Core level: {{{ A.f = \ (x_aqM :: GHC.Prim.Int#) -> case GHC.Prim.># x_aqM 0 of _ { __DEFAULT -> GHC.Types.I# (GHC.Prim.negateInt# x_aqM); 1 -> GHC.Types.I# x_aqM } }}} but the code genrator produces very bad Cmm code, because it pushes heap checks into case alternatives: {{{ {offset cFd: // stack check if ((Sp + -16) < SpLim) goto cFr; else goto cFs; cFr: // not enough place on the stack, call GC R2 = R2; R1 = A.f_closure; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; cFs: // scrutinize (x ># 0#) _sEU::I64 = R2; _sEV::I64 = %MO_S_Gt_W64(R2, 0); if (_sEV::I64 != 1) goto cFg; else goto cFo; cFg: // False branch Hp = Hp + 16; if (Hp > HpLim) goto cFy; else goto cFx; cFy: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFf; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFf, args: 8, res: 8, upd: 8; cFf: // re-do the False branch _sEU::I64 = I64[Sp + 8]; Sp = Sp + 16; _sEV::I64 = R1; goto cFg; cFx: // RHS of False branch I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = -_sEU::I64; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; cFo: // True branch Hp = Hp + 16; if (Hp > HpLim) goto cFv; else goto cFu; cFv: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFn; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFn, args: 8, res: 8, upd: 8; cFn: // re-do the True branch _sEU::I64 = I64[Sp + 8]; Sp = Sp + 16; _sEV::I64 = R1; goto cFo; cFu: // RHS of True branch I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = _sEU::I64; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }}} This results in average 2.5% increase in binary size. By contrast, if we use `tagToEnum#` instead of `isTrue#` heap check will be placed before `case` expression and the code will be significantly shorter (this is done by a special case-on-bool optimization in the code generator - see #8317). What we would like to do here is: 1. compile case alternatives without placing heap checks inside them 2. each compiled alternative should return amount of heap it needs to allocate 3. code generator inspects amounts of heap needed by each alternative and either adds heap checks in alternatives or puts a single check before the case expression. Getting this right might be a bit tricky. 1. if all branches allocate some heap then we can just put a common heap check before the case. Note that we must allocate the higgest amount required by any of the alternatives and then alternatives that use less heap must retract the heap pointer accordingly. 2. if we have two alternatives, one of which allocates heap and the other does not, we should place the heap check only in the alternative that allocates the stack. This will solve #1498. 3. it is not clear to me what to do if we have combination of the above (more than one branch that allocates heap and at least one branch that does not). If we place heap check before the `case` expression we lose optimization of recursive functions and face the problem described in #1498. If we push heap checks into branches that allocate heap then we get code duplication, i.e. the problem that we're addressing in this ticket. I guess the only way to make correct decission here is to try different aproaches and measure their performance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8326> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

[GHC] #14366: Type family equation refuses to unify wildcard type patterns
by GHC 05 Jan '19

05 Jan '19

#14366: Type family equation refuses to unify wildcard type patterns -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This typechecks: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} import Data.Kind import Data.Type.Equality type family Cast (e :: a :~: b) (x :: a) :: b where Cast Refl x = x }}} However, if you try to make the kinds `a` and `b` explicit arguments to `Cast`: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} import Data.Kind import Data.Type.Equality type family Cast (a :: Type) (b :: Type) (e :: a :~: b) (x :: a) :: b where Cast _ _ Refl x = x }}} Then GHC gets confused: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:9:12: error: • Expected kind ‘_ :~: _1’, but ‘'Refl’ has kind ‘_ :~: _’ • In the third argument of ‘Cast’, namely ‘Refl’ In the type family declaration for ‘Cast’ | 9 | Cast _ _ Refl x = x | ^^^^ }}} A workaround is to explicitly write out what should be inferred by the underscores: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} import Data.Kind import Data.Type.Equality type family Cast (a :: Type) (b :: Type) (e :: a :~: b) (x :: a) :: b where Cast a a Refl x = x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14366> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11829: C++ does not catch exceptions when used with Haskell-main and linked by ghc
by GHC 05 Jan '19

05 Jan '19

#11829: C++ does not catch exceptions when used with Haskell-main and linked by ghc -------------------------------------+------------------------------------- Reporter: pl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | Keywords: c++ | Operating System: Unknown/Multiple exceptions | Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the C++ program {{{ // Main_cc.cc #include <iostream> #include <exception> extern "C" { int func() { try { throw std::runtime_error("THIS FAILS!"); } catch(const std::runtime_error &c) { std::cerr << c.what(); } return 0; } } }}} and the Haskell program {{{#!hs -- Main.hs module Main where import Foreign.C.Types foreign import ccall func :: IO CInt main :: IO () main = print =<< func }}} When compiled with {{{ ghc --make Main.hs Main_cc.cc -lstdc++ }}} and being run on mac os x 10.11.3 the result is {{{ libc++abi.dylib: terminating with uncaught exception of type std::runtime_error: THIS FAILS! Abort trap: 6 }}} and not (as it should be): {{{ THIS FAILS!0 }}} When compiled in a similar way under windows some c++ exceptions of a larger project are not caught as well. However, these were hard to track down and I was unable to construct a simple example like the one above. As a workaround one can * write a main() function in c++ and call from there into Haskell, * compile the Haskell-Module with the options "-c -no-hs-main", and * link the application using g++ (not ghc!). When being compiled / linked this way, all c++ exceptions are being caught in mac os x as well as under windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11829> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13630: ByteString pinned memory can be leaky
by GHC 04 Jan '19

04 Jan '19

#13630: ByteString pinned memory can be leaky -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- My question on IRC: {{{ How does memory allocation for pinned blocks work? Let's say pinned blocks are 4KB in size, and I allocate first a 3 KB ByteString A and then an 8-byte ByteString B. Now I GC A, no longer need it. Then according to https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/Pinned "a single pinned object keeps alive the whole block in which it resides", my small ByteString B keeps the entire block alive. But what happens with the 3KB in the front of that block? Will it be re-used by the next ByteString allocation (say 1KB)? In other words, how smart is allocatePinned as an allocator? }}} The answer: {{{ slyfox: nh2: allocatePinned it quite dump. it only allocated from free tail space }}} {{{ nh2: slyfox: that sounds like a huge potential for memory leak then slyfox: yes, fragmentation is quite bad for bytestrings }}} So it seems that I can get into the unfortunate situation where a super short `ByteString` of a few bytes can waste an entire 4 KB block of memory; some migth call this a leak. One idea to solve it seems to be to change standard `ByteStrings` to not pinned, and to allocate pinned ones explicitly when needed. This seems to be an often-discussed topic and not trivial because many `ByteString` functions are implemented using libc FFI functions. However, it seems there will always be _some_ need for pinned memory, so we should better have an efficient way to manage it in any case. Efficient here means, for example, to re-use freed memory inside a block instead of only using free tail space. It seems that `jemalloc` has a feature to use given blocks of memory and provide a `malloc()` functionality inside them: https://stackoverflow.com/questions/30836359/jemalloc-mmap-and-shared- memory Perhaps this could be used to provide GHC with a simple method to use pinned memory more efficiently? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13630> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14797: High-residency modules during GHC build
by GHC 04 Jan '19

04 Jan '19

#14797: High-residency modules during GHC build -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying to figure out memory allocation failures on the CI server, I tracked allocations and residency on a per-module basis, and noticed that some modules require a lot more memory to compile than others. I've compiled a digest of the most memory-hungry compilation steps: {{{ "/usr/local/bin/ghc" ... compiler/stage1/build/OptCoercion.o: Max. residency: 991356584 / In use: 2094M "inplace/bin/ghc-stage1" ... compiler/stage2/build/OptCoercion.dyn_o: Max. residency: 714940528 / In use: 1471M "/usr/local/bin/ghc" ... compiler/stage1/build/X86/CodeGen.o: Max. residency: 679947656 / In use: 1497M "inplace/bin/ghc-stage1" ... libraries/Cabal/Cabal/dist- install/build/Distribution/SPDX/LicenseId.dyn_o: Max. residency: 653177496 / In use: 1355M "inplace/bin/ghc-stage1" ... compiler/stage2/build/X86/CodeGen.dyn_o: Max. residency: 641515344 / In use: 1425M "/usr/local/bin/ghc" ... -ilibraries/parsec: Max. residency: 593335568 / In use: 1355M "/usr/local/bin/ghc" ... libraries/Cabal/Cabal/dist- boot/build/Distribution/SPDX/LicenseId.o: Max. residency: 575034968 / In use: 1137M "inplace/bin/ghc-stage1" ... compiler/stage2/build/DynFlags.dyn_o: Max. residency: 402734408 / In use: 1059M "/usr/local/bin/ghc" ... compiler/stage1/build/DynFlags.o: Max. residency: 343154784 / In use: 892M "inplace/bin/ghc-stage1" ... libraries/template-haskell/dist- install/build/Language/Haskell/TH/Syntax.dyn_o: Max. residency: 266744312 / In use: 720M "/usr/local/bin/ghc" ... compiler/stage1/build/Parser.o: Max. residency: 258613584 / In use: 679M "inplace/bin/ghc-stage1" ... compiler/stage2/build/CmmOpt.dyn_o: Max. residency: 254639624 / In use: 568M "inplace/bin/ghc-stage1" ... compiler/stage2/build/Parser.dyn_o: Max. residency: 236774592 / In use: 635M "inplace/bin/ghc-stage1" ... ghc/stage2/build/GHCi/UI.dyn_o: Max. residency: 234055792 / In use: 609M "/usr/local/bin/ghc" ... compiler/stage1/build/HsExpr.o: Max. residency: 233724400 / In use: 657M "/usr/local/bin/ghc" ... compiler/stage1/build/CmmOpt.o: Max. residency: 208378888 / In use: 436M "/usr/local/bin/ghc" ... compiler/stage1/build/HscMain.o: Max. residency: 197177248 / In use: 500M "inplace/bin/ghc-stage1" ... compiler/stage2/build/HsExpr.dyn_o: Max. residency: 192780496 / In use: 521M "inplace/bin/ghc-stage1" ... libraries/Cabal/Cabal/dist- install/build/Distribution/Simple/Setup.dyn_o: Max. residency: 191649952 / In use: 521M "/usr/local/bin/ghc" ... compiler/stage1/build/HsDecls.o: Max. residency: 183441120 / In use: 508M "inplace/bin/ghc-stage1" ... compiler/stage2/build/TcSplice.dyn_o: Max. residency: 176802000 / In use: 445M "inplace/bin/ghc-stage1" ... compiler/stage2/build/TcRnDriver.dyn_o: Max. residency: 172892128 / In use: 458M "inplace/bin/ghc-stage1" ... compiler/stage2/build/HscMain.dyn_o: Max. residency: 172802688 / In use: 470M "inplace/bin/ghc-stage1" ... libraries/ghci/dist- install/build/GHCi/TH/Binary.dyn_o: Max. residency: 169775368 / In use: 455M "inplace/bin/ghc-stage1" ... compiler/stage2/build/GhcMake.dyn_o: Max. residency: 167305408 / In use: 431M "inplace/bin/ghc-stage1" ... compiler/stage2/build/PrimOp.dyn_o: Max. residency: 162532408 / In use: 455M "/usr/local/bin/ghc" ... compiler/stage1/build/HscTypes.o: Max. residency: 160814736 / In use: 421M "inplace/bin/ghc-stage1" ... compiler/stage2/build/HsDecls.dyn_o: Max. residency: 160445552 / In use: 426M "inplace/bin/ghc-stage1" ... libraries/Cabal/Cabal/dist- install/build/Language/Haskell/Extension.dyn_o: Max. residency: 159817712 / In use: 363M "/usr/local/bin/ghc" ... compiler/stage1/build/TcSplice.o: Max. residency: 156738656 / In use: 375M "/usr/local/bin/ghc" ... compiler/stage1/build/TcRnDriver.o: Max. residency: 153910768 / In use: 421M "inplace/bin/ghc-stage1" ... libraries/containers/dist- install/build/Data/Sequence/Internal.dyn_o: Max. residency: 151318224 / In use: 405M "inplace/bin/ghc-stage1" ... compiler/stage2/build/MatchLit.dyn_o: Max. residency: 150681176 / In use: 382M "/usr/local/bin/ghc" ... compiler/stage1/build/ByteCodeGen.o: Max. residency: 144579176 / In use: 389M "/usr/local/bin/ghc" ... compiler/stage1/build/GhcMake.o: Max. residency: 144411312 / In use: 379M "/usr/local/bin/ghc" ... compiler/stage1/build/MatchLit.o: Max. residency: 142596736 / In use: 382M "inplace/bin/ghc-stage1" ... compiler/stage2/build/StgCmmPrim.dyn_o: Max. residency: 141484616 / In use: 340M "inplace/bin/ghc-stage1" ... libraries/ghci/dist- install/build/GHCi/Message.dyn_o: Max. residency: 139224136 / In use: 363M "/usr/local/bin/ghc" ... compiler/stage1/build/StgCmmPrim.o: Max. residency: 137390744 / In use: 346M "inplace/bin/ghc-stage1" ... compiler/stage2/build/TcExpr.dyn_o: Max. residency: 136387128 / In use: 370M "inplace/bin/ghc-stage1" ... compiler/stage2/build/Lexer.dyn_o: Max. residency: 135228120 / In use: 337M "inplace/bin/ghc-stage1" ... compiler/stage2/build/TcTyClsDecls.dyn_o: Max. residency: 134817024 / In use: 369M "/usr/local/bin/ghc" ... compiler/stage1/build/MkIface.o: Max. residency: 134039144 / In use: 339M "inplace/bin/ghc-stage1" ... compiler/stage2/build/RnExpr.dyn_o: Max. residency: 133947600 / In use: 345M "inplace/bin/ghc-stage1" ... compiler/stage2/build/HscTypes.dyn_o: Max. residency: 133938840 / In use: 366M "inplace/bin/ghc-stage1" ... compiler/stage2/build/TcGenDeriv.dyn_o: Max. residency: 133744056 / In use: 320M "/usr/local/bin/ghc" ... compiler/stage1/build/TcExpr.o: Max. residency: 131766896 / In use: 336M "inplace/bin/ghc-stage1" ... compiler/stage2/build/GHC.dyn_o: Max. residency: 130998912 / In use: 277M "inplace/bin/ghc-stage1" ... compiler/stage2/build/ByteCodeGen.dyn_o: Max. residency: 129499464 / In use: 348M "inplace/bin/ghc-stage1" ... compiler/stage2/build/InteractiveEval.dyn_o: Max. residency: 128902944 / In use: 286M }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14797> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2