April 2018 - ghc-tickets

[GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects
by GHC 31 May '18

31 May '18

#14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Keywords: | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm opening a fresh ticket as @bgamari suggested in #12479. There are few more related closed tickets as well: #12198 and #12588. The issue occurs on projects with a lot of dependencies. There are reports of that happening across various projects: [https://github.com/NixOS/nixpkgs/issues/22810] [https://github.com/commercialhaskell/stack/issues/2577] I'm still able to reproduce it with 8.2.1 and git HEAD with a work project: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/f8/2_rc4tgd1gj9vbgv7q9gbk4c0000gn/T/ghc94377_0/libghc_325.dylib, 5): no suitable image found. Did find: /var/folders/f8/2_rc4tgd1gj9vbgv7q9gbk4c0000gn/T/ghc94377_0/libghc_325.dylib: malformed mach-o: load commands size (34592) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I can't share the sources, but this is a command(generated by stack) that results in this error: `/Users/dr/.stack/setup-exe-cache/x86_64-osx/Cabal- simple_mPHDZzAJ_2.0.0.2_ghc-8.2.1 --builddir=.stack- work/dist/x86_64-osx/Cabal-2.0.0.2 build lib:projectname exe:projectname --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"` We're having a chat about this issue with @bgamari and I'll post some of his input: {{{ bgamari: dredozubov, unfortunately this is pretty much a limitation of OS X's linker bgamari: there's no great solution other than petitioning Apple to lift their arbitrary size limit bgamari: I've been asking people to open tickets with Apple bgamari: As they are really the only ones that can really fix this issue dredozubov: bgamari, do you know if someone did this already? bgamari: dredozubov, No one has said they have dredozubov: the other issue with it, I don't how to do a repro case dredozubov: I can reproduce it on a project with a closed sources and that's it bgamari: essentially you just need to build a project with enough dependencies bgamari: the problem is that Apple's linker sets an artificial cap on the number of shared libraries that an object file can load }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14444> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #15104: Update JMP_TBL targets during shortcutting for x86 codegen.
by GHC 31 May '18

31 May '18

#15104: Update JMP_TBL targets during shortcutting for x86 codegen. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (NCG) | Keywords: CodeGen | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4595 | Wiki Page: -------------------------------------+------------------------------------- Jump tables are generated from Cmm Code in a few steps: 1. We start with a CmmSwitch at the end of the Cmm pipeline which gets turned into a JMP_TBL instruction. 2. During native codegen we generate static jump tables from JMP_TBL. (generateJumpTables) 3. We shortcut jump targets, for jump tables by updating the static tables. (shortcutBranches). This might update the jump targets with calculated address not represented by a label. After the third step the targets in the JMP_TBL instruction (which are the original labels) and in the static data can be out of sync. Phab:D4566 went part of the way, updating labels in JMP_TBL. However without tables next to code labels can be updated to non-label jump destinations which I did not consider at the time. Phab:D4595 is intended to fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15104> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9479: Report required constraints when reporting the type of a hole
by GHC 30 May '18

30 May '18

#9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: dominiquedevriese | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: holes | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- For the following code {{{ module Test where test :: String test = show _h }}} GHC currently reports: {{{ Found hole ‘_h’ with type: a0 Where: ‘a0’ is an ambiguous type variable Relevant bindings include test :: String (bound at /tmp/Test.hs:4:1) In the first argument of ‘show’, namely ‘_h’ In the expression: show _h In an equation for ‘test’: test = show _h }}} It correctly does not report the lack of a `Show _a` instance as a separate type error. However, it would be useful if the report containing the type of the hole would also contain the constraints that apply to its type. Something like: {{{ Found hole ‘_h’ with type: a0 Where: ‘a0’ is an ambiguous type variable Applicable constraints: Show a0 Relevant bindings include test :: String (bound at /tmp/Test.hs:4:1) In the first argument of ‘show’, namely ‘_h’ In the expression: show _h In an equation for ‘test’: test = show _h }}} I am explicitly *not* suggesting to report a type like `Show a0 => a0` for the hole, because that might mistakenly suggest that we are looking for a value of type `forall a0. Show a0 => a0`, which we are not. A possible alternative is to use an imaginary exists type like `exists a0. Show a0 => a0` but that's probably just even more confusing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9479> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15088: Test T3234 is fragile
by GHC 30 May '18

30 May '18

#15088: Test T3234 is fragile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The test for T3234 is quite fragile as it compares the whole output of `-ddump-simpl-stats`. #3234 should be consulted and then the test modified so that only the relevant part is extracted and compared. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15088> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS
by GHC 30 May '18

30 May '18

#12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 this bare-bones module {{{#!hs {-# OPTIONS -fplugin GHC.TypeLits.Normalise #-} module A where }}} compiling it will always say {{{ $ ghc --make A.hs [1 of 1] Compiling A ( A.hs, A.o ) [GHC.TypeLits.Normalise changed] }}} even when the module was compiled before. {{{ $ ghc A.hs -c -ddump-if-trace -ddump-hi-diffs }}} will give the reason: {{{ imported module ‘GHC.TypeLits.Normalise’ is from package ‘ghc-typelits- natnormalise-0.5’, which is not among previous dependencies }}} Which is the probable cause: when writing the `.hi` file, the used plugins' package dependencies should be also written out. AFAICS they are extracted fron the `DynFlags` but for this comparison in {{{ checkDependencies :: HscEnv -> ModSummary -> ModIface -> IfG RecompileRequired }}} but not found in the `ModSummary` that was originally written to disk. This is pretty nasty for `clash` compilations and the suspected bug is documented here: https://github.com/clash-lang/ghc-typelits- natnormalise/issues/2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12567> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13838: -Wdeferred-type-errors; ghc: panic!; VoidRep; ((() -> ()) :: *) ~# (IO Any :: *)
by GHC 30 May '18

30 May '18

#13838: -Wdeferred-type-errors; ghc: panic!; VoidRep; ((() -> ()) :: *) ~# (IO Any :: *) -------------------------------------+------------------------------------- Reporter: harry | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- My Compiler told me to report this so here you go: {{{ [1 of 1] Compiling Main ( ghc_bug.hs, interpreted ) ghc_bug.hs:3:1: warning: [-Wdeferred-type-errors] * Couldn't match expected type `IO t0' with actual type `() -> ()' * Probable cause: `main' is applied to too few arguments In the expression: main When checking the type of the IO action `main' ghc_bug.hs:3:8: warning: [-Wdeferred-type-errors] * Couldn't match expected type `() -> () -> ()' with actual type `()' * The function `()' is applied to one argument, but its type `()' has none In the expression: () () In an equation for `main': main = () () ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): corePrepPgm [False] cobox_r1a0 = typeError @ 'VoidRep @ ((() -> ()) :: *) ~# (IO Any :: *) "ghc_bug.hs:3:1: error:\n\ \ * Couldn't match expected type `IO t0' with actual type `() -> ()'\n\ \ * Probable cause: `main' is applied to too few arguments\n\ \ In the expression: main\n\ \ When checking the type of the IO action `main'\n\ \(deferred type error)"# Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{#!hs main :: () -> () main = () () }}} which that in "ghc_bug.hs" "ghc ghc_bug.hs -fdefer-type-errors -dcore-lint -v" gives me the following: {{{ Glasgow Haskell Compiler, Version 8.0.1, stage 2 booted by GHC version 7.10.3 Using binary package database: /usr/lib/ghc-8.0.1/package.conf.d/package.cache Using binary package database: /home/harry/.ghc/x86_64-linux-8.0.1/package.conf.d/package.cache loading package database /usr/lib/ghc-8.0.1/package.conf.d loading package database /home/harry/.ghc/x86_64-linux-8.0.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.0.1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: loading package database /usr/lib/ghc-8.0.1/package.conf.d loading package database /home/harry/.ghc/x86_64-linux-8.0.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.0.1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *ghc_bug.hs !!! Chasing dependencies: finished in 0.42 milliseconds, allocated 0.211 megabytes Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = ****-**-** **:**:**.********** *** ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file ghc_bug.hs *** Checking old interface for Main: [1 of 1] Compiling Main ( ghc_bug.hs, ghc_bug.o ) *** Parser [Main]: !!! Parser [Main]: finished in 0.14 milliseconds, allocated 0.089 megabytes *** Renamer/typechecker [Main]: !!! Renamer/typechecker [Main]: finished in 28.70 milliseconds, allocated 14.769 megabytes *** Desugar [Main]: Result size of Desugar (after optimization) = {terms: 19, types: 52, coercions: 4} *** Core Linted result of Desugar (after optimization): *** Core Lint errors : in result of Desugar (after optimization) *** <no location info>: warning: [RHS of cobox_aOD :: ((() -> ()) :: *) ~# (IO Any :: *)] The type of this binder is primitive: cobox_aOD Binder's type: ((() -> ()) :: *) ~# (IO Any :: *) *** Offending Program *** main :: () -> () [LclIdX, Str=DmdType] main = case typeError @ 'VoidRep @ (() :: *) ~# ((() -> () -> ()) :: *) "ghc_bug.hs:2:8: error:\n\ \ * Couldn't match expected type `() -> () -> ()'\n\ \ with actual type `()'\n\ \ * The function `()' is applied to one argument,\n\ \ but its type `()' has none\n\ \ In the expression: () ()\n\ \ In an equation for `main': main = () ()\n\ \(deferred type error)"# of cobox_aOE { __DEFAULT -> (() `cast` (Sub cobox_aOE :: (() :: *) ~R# ((() -> () -> ()) :: *))) () } $trModule :: Module [LclIdX, Str=DmdType] $trModule = Module (TrNameS "main"#) (TrNameS "Main"#) cobox_aOD :: ((() -> ()) :: *) ~# (IO Any :: *) [LclId[CoVarId], Str=DmdType] cobox_aOD = typeError @ 'VoidRep @ ((() -> ()) :: *) ~# (IO Any :: *) "ghc_bug.hs:2:1: error:\n\ \ * Couldn't match expected type `IO t0' with actual type `() -> ()'\n\ \ * Probable cause: `main' is applied to too few arguments\n\ \ In the expression: main\n\ \ When checking the type of the IO action `main'\n\ \(deferred type error)"# main :: IO Any [LclIdX, Str=DmdType] main = runMainIO @ Any (main `cast` (Sub cobox_aOD :: ((() -> ()) :: *) ~R# (IO Any :: *))) *** End of Offense *** <no location info>: error: Compilation had errors *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: }}} and gcc version is: gcc version 7.1.1 20170516 (GCC) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13838> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14969: panic on incorrect syntax
by GHC 30 May '18

30 May '18

#14969: panic on incorrect syntax -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- With a fresh build of 8.5: {{{ GHCi, version 8.5.20180323: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/leo/.ghci Prelude> 3 _ 4 ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180323 for x86_64-apple-darwin): ASSERT failed! 2 1 t_a4j6[tau:1] Maybe a_a4j7[tau:2] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1157:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1213:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcMType.hs:720:54 in ghc:TcMType }}} I believe this fails in earlier versions as well, but I haven't tested it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14969> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #15073: Unable to newtype derive `Prim` via DerivingStrategies
by GHC 30 May '18

30 May '18

#15073: Unable to newtype derive `Prim` via DerivingStrategies -------------------------------------+------------------------------------- Reporter: fosskers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following compiles with both GHC 8.2.2 and 8.4.1: {{{#!hs newtype Drain = Drain { _drain :: Word8 } deriving stock (Eq, Ord, Show, Generic) deriving newtype (Storable) deriving anyclass (NFData) }}} However, adding `Prim` beside `Storable` in the `newtype` area yields the following with GHC 8.2.2: {{{ /home/colin/code/haskell/mapalgebra/lib/Geography/MapAlgebra.hs:1148:21-24: error: • Illegal unboxed tuple type as function argument: (# ghc-prim-0.5.1.1:GHC.Prim.State# s1, Word8 #) • In the expression: ghc-prim-0.5.1.1:GHC.Prim.coerce @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep). ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s -> ghc-prim-0.5.1.1:GHC.Prim.Int# -> ghc-prim-0.5.1.1:GHC.Prim.State# s -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Word8) @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep). ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s -> ghc-prim-0.5.1.1:GHC.Prim.Int# -> ghc-prim-0.5.1.1:GHC.Prim.State# s -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Drain) primitive-0.6.3.0:Data.Primitive.Types.readByteArray# In an equation for ‘primitive-0.6.3.0:Data.Primitive.Types.readByteArray#’: primitive-0.6.3.0:Data.Primitive.Types.readByteArray# = ghc-prim-0.5.1.1:GHC.Prim.coerce @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep). ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s -> ghc-prim-0.5.1.1:GHC.Prim.Int# -> ghc-prim-0.5.1.1:GHC.Prim.State# s -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Word8) @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep). ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s -> ghc-prim-0.5.1.1:GHC.Prim.Int# -> ghc-prim-0.5.1.1:GHC.Prim.State# s -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Drain) }}} and this with GHC 8.4.1: {{{ Illegal kind: ((:) (ghc-prim-0.5.2.0:GHC.Types.TupleRep ([] :: [] ghc- prim-0.5.2.0:GHC.Types.RuntimeR ep)) ((:) ghc-prim-0.5.2.0:GHC.Types.LiftedRep ([] :: [] ghc- prim-0.5.2.0:GHC.Types.RuntimeRep) :: [] ghc-prim-0.5.2.0:GHC.Types.RuntimeRep) :: [] ghc- prim-0.5.2.0:GHC.Types.RuntimeRep) Did you mean to enable TypeInType? | 1132 | deriving newtype (Storable, Prim) | }}} Turning on `TypeInType` as it suggests gives the same `Illegal unboxed tuple...` error. I've hand-written `Storable` instances before so I'm confident in its derivation, but I otherwise know nothing about `Prim`. Is there something magical about it that prevents it from being newtype derived in the same way? Thank you kindly, Colin -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15073> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15060: outofmem testcase sometimes crashes on i386
by GHC 30 May '18

30 May '18

#15060: outofmem testcase sometimes crashes on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.2.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Specifically in the `normal` way with, {{{ Actual stderr output differs from expected: --- ./rts/outofmem.run/outofmem.stderr-ws-32.normalised 2018-04-19 13:57:35.386373403 +0000 +++ ./rts/outofmem.run/outofmem.run.stderr.normalised 2018-04-19 13:57:35.386373403 +0000 @@ -1 +1,4 @@ -outofmem: out of memory (requested 1074790400 bytes) +outofmem: internal getMBlock: mmap: Invalid argument + (GHC version 8.5.20180419 for i386_unknown_linux) + Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug +Aborted *** unexpected failure for outofmem(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15060> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14789: GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at prompt
by GHC 30 May '18

30 May '18

#14789: GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at prompt -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This was recently reported on Stack Overflow (https://stackoverflow.com/questions/48723119/binding-len-length-xs-and- then-calculating-len-causes-ghc-to-consume-lots). With GHC 8.2.2, assigning the length of a large list as a top-level declaration at the GHCi prompt and evaluating it: {{{ Prelude> l = length [1..10^8] Prelude> l 10000000 Prelude> }}} allocates about 7 gigs of memory before displaying a result, and then memory continues to grow over the next few seconds (at the idle GHCi prompt) until 10 gigs of memory has been allocated. None of it is freed until the interpreter session ends. In contrast, directly evaluating the expression or assigning it with a let-statement does **not** exhibit this behavior: {{{ Prelude> length [1..10^8] 10000000 Prelude> let l = length [1..10^8] Prelude> l 10000000 Prelude> }}} Also, loading the top-level declaration from a file and then evaluating it at the prompt does **not** exhibit the problem. I took a look at Ticket [ticket: 14336] and applied the `-fno-it` patch referenced there. This slightly changed the pattern of memory usage: it grew to about 4 gigs before displaying the result, but then continued to grow for several seconds at the GHCi prompt before landing at about 10 gigs. I verified that the bug still exists on the current "master" branch (though I didn't check the "ghc-8.4" branch). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14789> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2