February 2018 - ghc-tickets

[GHC] #14792: compiling cabal-1.24.2.0 requires almost 3 GB of memory
by GHC 11 Feb '18

11 Feb '18

#14792: compiling cabal-1.24.2.0 requires almost 3 GB of memory -------------------------------------+------------------------------------- Reporter: bfrk | 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: -------------------------------------+------------------------------------- Not sure if this is really a bug, but I noticed that ghc-8.2.2 requires a whole lot more memory than ghc-7-10.3. This is how I found out about it: {{{ ben@yuiitsu[1]:.../src/Cabal-1.24.2.0>ulimit -v 2600000 ben@yuiitsu[1]:.../src/Cabal-1.24.2.0>cabal new-build Resolving dependencies... Build profile: -w ghc-8.2.2 -O1 In order, the following will be built (use -v for more details): - Cabal-1.24.2.0 (lib) (first run) Configuring library for Cabal-1.24.2.0.. Preprocessing library for Cabal-1.24.2.0.. Building library for Cabal-1.24.2.0.. [ 1 of 86] Compiling Distribution.Compat.Binary ( Distribution/Compat/Binary.hs, /home/ben/src/Cabal-1.24.2.0/dist- newstyle/build/x86_64-linux/ghc-8.2.2/Cabal-1.24.2.0/build/Distribution/Compat/Binary.o ) [...] [30 of 86] Compiling Distribution.PackageDescription ( Distribution/PackageDescription.hs, dist/build/Distribution/PackageDescription.o ) ghc: out of memory cabal: Failed to build Cabal-1.24.2.0 (which is required by darcs-2.13.0). The build process terminated with exit code 251 }}} It works when I ulimit -v 3000000. I previously had the limit at 2200000 and it worked just fine with ghc-7.10.3. The reason i limit the memory available to ghc is to avoid my machine freezing up due to thrashing (I only have 4GB physical RAM). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14792> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14786: Compile-time panic with kind-level application in type famiy decl
by GHC 10 Feb '18

10 Feb '18

#14786: Compile-time panic with kind-level application in type famiy decl -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Minimal example: {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} type family E e (a :: k) (orn :: e a) :: () }}} Error message: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): getRuntimeRep k_anW[sk:1] :: k0_aRs[tau:1] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1967:18 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14786> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
by GHC 09 Feb '18

09 Feb '18

#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by atravers): Replying to [comment:49 simonpj]: Starting with the following local definitions of computeInOuts, in section 5.4 of the Diatchki/Jones/Hallgren paper: {{{ nextExps = computeEs . computeIs computeEs is = zipWith exports mods is computeIs es = map (`inscope` toFun es) mods }}} which can be simplified to: {{{ nextExps es = map (computeModExps es) mods computeModExps es m = exports m (inscope m (toFun es)) }}} Then: {{{ nextExps es = map (computeModExps es) mods computeModExps es m = fst (compileMod es m) }}} ...assuming this can be well-defined: {{{ compileMod es m = (modExps, modCode) where modExps = exports m (inscope m (toFun es)) modCode = ... . . . }}} Would something like this be possible in GHC? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1409#comment:72> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14765: Levity polymorphism panic
by GHC 09 Feb '18

09 Feb '18

#14765: Levity polymorphism panic -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- I imagine I have made a mistake, but GHC shouldn't panic! {{{#!hs {-# language TypeInType, ScopedTypeVariables, MagicHash #-} import GHC.Exts (TYPE, Proxy#, proxy#) fold :: forall rep a (r :: TYPE rep). (r -> a -> Proxy# r -> r) -> (Proxy# r -> r) -> [a] -> r fold f k [] = k proxy# fold f k (x : xs) = fold f (f (k proxy#) x) xs }}} This gives me {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20171211 for x86_64-unknown-linux): splitFunTy () Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:921:30 in ghc:Type }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14765> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7259: Eta expansion of products in System FC
by GHC 09 Feb '18

09 Feb '18

#7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): This is currently imperilled by #14420. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7259#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6087: Join points need strictness analysis
by GHC 09 Feb '18

09 Feb '18

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Interesting. Some thoughts * CPR for sum types was introduced in #5075. * The initial motivation was for non-recursive types like `Maybe` and `Either`. Here it seems quite likely that the caller will case-analyse the result, so exposing the result constructor to the caller is good. * You point out that for recursive types, like lists, we typically ''don't'' case-analyse the result, so nothing is gained by the CPR. Maybe we should disable CPR for ''recursive'' sum types. * It's hard to come with a rigorous notion of what a "recursive" sum-type is, but any reasonable approximation will do. * Disabling CPR for `late-dmd-anal` seems unprincipled, and doesn't catch the cases described in #5075. * I note that comment:10 of #5075 identifies that the transformation is switched off for non-top-level definitions. See `Note [CPR for sum types]` in `DmdAnal`. But now that we have join points, the objection may no longer apply. It'd be interesting to try. * comment:12 of #5075 identifies three more tickets that claim to benefit from `late-dmd-anal`. Let's see if they do. * `cse` and `circsim` really do allocate (a little) more. But in your investigation you didn't find any allocation differences. Doesn't `-ticky` nail it for you? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7503: Bug with PolyKinds, type synonyms & GADTs
by GHC 09 Feb '18

09 Feb '18

#7503: Bug with PolyKinds, type synonyms & GADTs -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.1 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14451 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: GADTs => GADTs, TypeInType * related: => #14451 Comment: Adding this to `TypeInType` because it's really the same as #14451 which is so labelled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7503#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6087: Join points need strictness analysis
by GHC 09 Feb '18

09 Feb '18

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints 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: | -------------------------------------+------------------------------------- Comment (by osa1): I looked at `cse` and `circsim` which are smaller programs with increased allocation. Really the only difference I could find after a few hours of investigation is with `-flate-dmd-anal` we get new worker functions that return head and tail of a list in an unboxed tuple instead of returning a list. As far as I can see, the result is almost always packed back to a list at some point (somehwere in upper levels in the call stack). Overall the allocation should stay the same (because we allocate same number of cons cells, but allocate them in different places than we would without `-flate-dmd- anal`), so maybe this doesn't explain the allocation increase. Here's an example from `cse`, this is without late demand analysis: {{{ $wgo1_r6PF :: [GHC.Types.Char] -> GHC.Prim.Int# -> [GHC.Types.Char] [GblId, Arity=2, Str=<S,1*U><S,1*U>m2, Unf=OtherCon []] = sat-only [] \r [w_s6Uz ww_s6UA] case w_s6Uz of { [] -> $wxs1_r6PE ww_s6UA; : y_s6UC [Occ=Once*] ys_s6UD [Occ=Once] -> case ww_s6UA of ds11_s6UE { __DEFAULT -> let { sat_s6UG [Occ=Once] :: [GHC.Types.Char] [LclId] = [ys_s6UD ds11_s6UE] \u [] case -# [ds11_s6UE 1#] of sat_s6UF { __DEFAULT -> $wgo1_r6PF ys_s6UD sat_s6UF; }; } in : [y_s6UC sat_s6UG]; 1# -> : [y_s6UC n_r6Py]; }; }; }}} We generate this version with `-flate-dmd-anal`: {{{ $w$wgo_r6Yf :: [GHC.Types.Char] -> GHC.Prim.Int# -> (# GHC.Types.Char, [GHC.Types.Char] #) [GblId, Arity=2, Str=<S,1*U><S,1*U>, Unf=OtherCon []] = sat-only [] \r [w_s73c w1_s73d] case w_s73c of { [] -> $w$wxs_r6Ye w1_s73d; : y_s73f [Occ=Once*] ys_s73g [Occ=Once] -> case w1_s73d of ds11_s73h { __DEFAULT -> let { sat_s73m [Occ=Once] :: [GHC.Types.Char] [LclId] = [ys_s73g ds11_s73h] \u [] case -# [ds11_s73h 1#] of sat_s73i { __DEFAULT -> case $w$wgo_r6Yf ys_s73g sat_s73i of { (#,#) ww1_s73k [Occ=Once] ww2_s73l [Occ=Once] -> : [ww1_s73k ww2_s73l]; }; }; } in (#,#) [y_s73f sat_s73m]; 1# -> (#,#) [y_s73f n_r6Y9]; }; }; }}} Notice that in the recursive case we do the same thing in both cases, but with `-flate-dmd-anal` we pack the result in call site rather than returning packed result in the recursive call. The call sites look like this: (large code, pasting only the relevant parts) {{{ let { sat_s757 [Occ=Once, Dmd=<L,1*U>] :: [GHC.Types.Char] [LclId] = [ww_s751] \s [] case $w$wgo_r6Yf ww_s751 4# of { (#,#) ww3_s755 [Occ=Once] ww4_s756 [Occ=Once] -> : [ww3_s755 ww4_s756]; }; } in GHC.Base.++ ds10_r6Y7 sat_s757; }}} So we directly pack it again. Same transformation happens in `circsim` too. New worker: {{{ $w$wxs_rb9n :: GHC.Prim.Int# -> (# Main.Boolean, [Main.Boolean] #) [GblId, Arity=1, Caf=NoCafRefs, Str=<S,1*U>, Unf=OtherCon []] = sat-only \r [w_sbe6] case w_sbe6 of ds1_sbe7 { __DEFAULT -> let { sat_sbec [Occ=Once] :: [Main.Boolean] [LclId] = \u [] case -# [ds1_sbe7 1#] of sat_sbe8 { __DEFAULT -> case $w$wxs_rb9n sat_sbe8 of { (#,#) ww1_sbea [Occ=Once] ww2_sbeb [Occ=Once] -> : [ww1_sbea ww2_sbeb]; }; }; } in (#,#) [Main.T sat_sbec]; 1# -> (#,#) [Main.T GHC.Types.[]]; }; }}} exactly the same thing, recursive case directly packs the result. Call site: {{{ case $w$wxs_rb9n y1_sbA8 of { (#,#) ww1_sbAc [Occ=Once] ww2_sbAd [Occ=Once] -> : [ww1_sbAc ww2_sbAd]; }; }}} again result is directly packed. This happens in several places in both programs. I compared outputs both by mapping STG functions in outputs to each other manually and comparing the definitions, and also by using a diff tool to see if there are any extra code blocks etc. other than the ones I've already checked manually. These changes seem to be all unless I'm missing anything. I wonder what happens if I disable CPR in post-late-ww pass and only do worker-wrapper (not sure if it's currently possible but in theory it should be?). This should avoid the transformations described above, maybele still winning in the other cases? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14780: :type-at doesn't work when :load-ing with module name instead of file path
by GHC 08 Feb '18

08 Feb '18

#14780: :type-at doesn't work when :load-ing with module name instead of file path --------------------------------------+--------------------------- Reporter: jol | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------- After running {{{#!sh stack new something cd something }}} we have a file in src/Lib.hs with the contents: {{{#!hs module Lib ( someFunc ) where someFunc :: IO () someFunc = putStrLn "someFunc" }}} If we start `stack ghci`, we can have the following session showing the errors: {{{ > :set +c > :l Lib [1 of 1] Compiling Lib ( /home/jol/work- for/me/something/src/Lib.hs, interpreted ) Ok, one module loaded. Collecting type info for 1 module(s) ... > :type-at Lib 6 12 6 20 <no location info>: error: not an expression: ‘’ > :type-at src/Lib.hs 6 12 6 20 Couldn't guess that module name. Does it exist? }}} If we had done `:l src/Lib.hs` instead, then we can use the filepath like the following, but still not the module name: {{{ > :set +c > :l src/Lib.hs [1 of 1] Compiling Lib ( src/Lib.hs, interpreted ) Ok, one module loaded. Collecting type info for 1 module(s) ... > :type-at Lib 6 12 6 20 <no location info>: error: not an expression: ‘’ > :type-at src/Lib.hs 6 12 6 20 :: String -> IO () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14780> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14771: TypeError reported too eagerly
by GHC 08 Feb '18

08 Feb '18

#14771: TypeError reported too eagerly -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following example: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE UndecidableInstances #-} import GHC.TypeLits import Data.Proxy data DUMMY type family If c t e where If True t e = t If False t e = e type family F (n :: Nat) where --F n = If (n <=? 8) Int (TypeError (Text "ERROR")) F n = If (n <=? 8) Int DUMMY test :: (F n ~ Word) => Proxy n -> Int test _ = 2 test2 :: Proxy (n :: Nat) -> Int test2 p = test p main :: IO () main = do print (test2 (Proxy :: Proxy 5)) }}} The type error is useful: {{{ Bug.hs:26:11: error: • Couldn't match type ‘If (n <=? 8) Int DUMMY’ with ‘Word’ arising from a use of ‘test’ • In the expression: test p In an equation for ‘test2’: test2 p = test p • Relevant bindings include p :: Proxy n (bound at Bug.hs:26:7) test2 :: Proxy n -> Int (bound at Bug.hs:26:1) | 26 | test2 p = test p | ^^^^^^ }}} Now if we use the commented implementation of `F` (using `TypeError`), with GHC 8.2.2 and 8.0.2 we get: {{{ Bug.hs:26:11: error: • ERROR • In the expression: test p In an equation for ‘test2’: test2 p = test p | 26 | test2 p = test p | ^^^^^^ }}} While with GHC 8.0.1 we get: {{{ /home/hsyl20/tmp/Bug.hs:29:11: error: • Couldn't match type ‘If (n <=? 8) Int (TypeError ...)’ with ‘Word’ arising from a use of ‘test’ • In the expression: test p In an equation for ‘test2’: test2 p = test p }}} 1) Could we restore the behavior of GHC 8.0.1? 2) In my real code, when I use DUMMY I get: {{{ • Couldn't match type ‘If (n <=? 8) Int8 DUMMY’ with ‘Word’ Expected type: Word Actual type: F n }}} If we could get the same report (mentioning the "Actual type") when we use `TypeError` that would be great. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14771> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7