- ghc-tickets - Haskell.org

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 28 Jun '16

28 Jun '16

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rrnewton): One more small experiment. Before diving into the compiler internals, I thought it might be possible to do standard test case minimization. I.e. can we create some stub definitions for the relevant bits of `GHC.Generics`, while preserving the bad behavior? [https://gist.github.com/rrnewton/df17230b748df4ce1f06b49831348000 The file in this gist] attempts to do so, using the following stub definitions: {{{ class Generic a where from :: a -> M1 a data M1 a where M1 :: b -> M1 a data U1 p = U1 data (:+:) (f :: * -> *) (g :: * -> *) p = L1 (f p) | R1 (g p) }}} This is a lower bound -- it fails to produce the really slow behavior. It is simplified enough that the time for compiling just the "from" case drops from 5.7s all the way down to 0.85s. Getting back to the bad behavior will require putting more of the complexity of "M1" back into play... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:46> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 28 Jun '16

28 Jun '16

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rrnewton): Small addendum. If you split this up and compile the "from" and "to" methods separately, it is clear that most of the work is in the "from". On the small-four constructor examples: Version 1: * 239 coercions with both to/from. * 200 coercions with just "from" * 39 coercions with just "to" Version 2: * 174 coercions with both to/from. * 132 with just from * 42 with just "to" And on the full-sized, 300-way sums, here are the realtime measurements on my personal machine: Version 1: * both: 639K coercions, 7.0s * from-only: 636.9K coercions, 5.7s * to-only: 2K coercions, 1.8s Version 2: * both: 9.9K coercions, 4.4s * from-only: 7.5K coercions, 3.6s * to-only: 2.4K coercions, 1.0s At least in the bigger case, it looks like there is a drop in realtime for both of the from/to methods, with the former being constructor-heavy, and the latter being deep-pattern-match-heavy. Slicing it another way, if we cut down the cases in the 300-way match for "from-only"/v1 -- leaving incomplete pattern matches -- the coercions/time drops as follows: * 300 cases -- 636.9K coercions, 5.7s * 150 cases -- 316K coercions, 4.0s * 100 cases -- 212K coercions, 2.5s * 50 cases -- 106K coercions, 1.3s * 25 cases -- 53K coercions, 0.8s And "from-only"/v2: * 300 cases -- 7.5K coercions, 3.7s * 150 cases -- 5.8K coercions, 2.8s * 50 cases -- 4.8K coercions, 1.1s * 25 cases -- 4.5K coercions, 0.7s Ok, so nothing that unusual in this dimension. As should be expected, the "factored" v2 gets a larger benefit over v1 the more cases the factored bit is amortized over. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7298: GHCi is setting stdin/stdout to NoBuffering in runghc when DYNAMIC_GHC_PROGRAMS=YES
by GHC 28 Jun '16

28 Jun '16

#7298: GHCi is setting stdin/stdout to NoBuffering in runghc when DYNAMIC_GHC_PROGRAMS=YES -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghc-e/should_run/T2228 Blocked By: | Blocking: Related Tickets: #2228 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): See also ticket:12077#comment:7. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7298#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12235: Wrong compilation of bang patterns
by GHC 27 Jun '16

27 Jun '16

#12235: Wrong compilation of bang patterns -------------------------------------+------------------------------------- Reporter: osa1 | 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: -------------------------------------+------------------------------------- I have this function: {{{#!haskell fn5 :: Int -> [T] -> Int fn5 i [] = i fn5 i (A : ts) = fn5 (i + 1) ts fn5 !i (B : ts) = fn5 (i + 2) ts fn5 i (C : ts) = fn5 0 ts }}} This function should only `seq` the int after seeing that head of the list is `B`. But this is the generated code: (desugar) {{{#!haskell Rec { -- RHS size: {terms: 64, types: 33, coercions: 0} fn5 [Occ=LoopBreaker] :: Int -> [T] -> Int [LclIdX, Str=DmdType] fn5 = \ (i_ayA :: Int) (ds_d1Zb :: [T]) -> let { fail_d1Zn :: GHC.Prim.Void# -> Int [LclId, Str=DmdType] fail_d1Zn = \ _ [Occ=Dead, OS=OneShot] -> Control.Exception.Base.patError @ 'GHC.Types.PtrRepLifted @ Int "Main.hs:(41,1)-(44,25)|function fn5"# } in case ds_d1Zb of _ [Occ=Dead] { [] -> i_ayA; : ds_d1Zk ts_ayC -> case ds_d1Zk of _ [Occ=Dead] { __DEFAULT -> (\ _ [Occ=Dead, OS=OneShot] -> let { fail_d1Zp :: GHC.Prim.Void# -> Int [LclId, Str=DmdType] fail_d1Zp = \ _ [Occ=Dead, OS=OneShot] -> case ds_d1Zb of _ [Occ=Dead] { __DEFAULT -> fail_d1Zn GHC.Prim.void#; : ds_d1Zm ts_ayG -> case ds_d1Zm of _ [Occ=Dead] { __DEFAULT -> fail_d1Zn GHC.Prim.void#; C -> fn5 (GHC.Types.I# 0#) ts_ayG } } } in case i_ayA of i_XyO { __DEFAULT -> case ds_d1Zb of _ [Occ=Dead] { __DEFAULT -> fail_d1Zp GHC.Prim.void#; : ds_d1Zl ts_ayE -> case ds_d1Zl of _ [Occ=Dead] { __DEFAULT -> fail_d1Zp GHC.Prim.void#; B -> fn5 (+ @ Int GHC.Num.$fNumInt i_XyO (GHC.Types.I# 2#)) ts_ayE } } }) GHC.Prim.void#; A -> fn5 (+ @ Int GHC.Num.$fNumInt i_ayA (GHC.Types.I# 1#)) ts_ayC } } end Rec } }}} This code evaluates the list, and evaluates the int unless head of the list is `A`. I don't know why there's special case in A? In any case, this is wrong behavior as it forces the int in wrong times. As an example, this fails: {{{#!haskell fn5 :: Int -> [T] -> Int fn5 i [] = i fn5 i (A : ts) = fn5 (i + 1) ts fn5 !i (B : ts) = fn5 (i + 2) ts fn5 i (C : ts) = fn5 0 ts main = print (fn5 undefined [C]) }}} Tried with: GHC HEAD, 8.0.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12235> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #1965: Allow unconstrained existential contexts in newtypes
by GHC 25 Jun '16

25 Jun '16

#1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.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 Iceland_jack): Possible example from [http://www.cl.cam.ac.uk/~mpf23/papers/Types/gadtif.pdf A Foundation for GADTs and Inductive Families], encoding GADTs as left Kan extensions can be reworked to: {{{#!hs data N = O | S N data LanO j where LanO :: LanO (S i) data LanS j where LanS :: Fin i -> LanS (S i) }}} `Fin` defined as {{{#!hs data Fin a where FinO :: LanO i -> Fin i FinS :: LanS i -> Fin i pattern FinO' = FinO LanO pattern FinS' n = FinS (LanS n) }}} Do `LanO`, `LanS` satisfy the conditions to be newtypes? === Original code=== {{{#!hs data Fin :: * -> * where NZero :: Lan S One j -> Fin j NSucc :: Lan S Fin j -> Fin j data One j = One data Lan h _X j = forall i. Lan (Eql j (h i), _X i) data Eql i j where Refl :: Eql i i }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1965#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12184: unsafeCoerce# causing invalid assembly generation
by GHC 24 Jun '16

24 Jun '16

#12184: unsafeCoerce# causing invalid assembly generation -------------------------------------+------------------------------------- Reporter: osa1 | 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: -------------------------------------+------------------------------------- Discovered by MichaelBurge on IRC: {{{#!haskell {-# LANGUAGE MagicHash #-} import GHC.Prim import GHC.Types x = D# ((unsafeCoerce# (5# :: Int#) :: Double#) +## 5.0##) main = putStrLn $ show x }}} Compile with GHC 7.8, 8.0.1 or HEAD: {{{ [1 of 1] Compiling Main ( weird.hs, weird.o ) /tmp/ghc23262_0/ghc_2.s: Assembler messages: /tmp/ghc23262_0/ghc_2.s:43:0: error: Error: junk `naughty x86_64 register' after expression `gcc' failed in phase `Assembler'. (Exit code: 1) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12183: Display all relevant local bindings
by GHC 24 Jun '16

24 Jun '16

#12183: Display all relevant local bindings -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- Presently, "Relevant bindings" messages (e.g., from holes) will attempt to report all local bindings, and relevant global bindings (by some heuristic), up to the number of bindings specified by `-fmax-relevant- binds=N`. For example, here is an error I recently had with a small number of relevant bindings: {{{ Productive.hs:162:16: error: • Found hole: _ :: Par (D k0 (Stream k0 b)) Where: ‘k0’ is an ambiguous type variable ‘b’ is a rigid type variable bound by the type signature for: maapM :: forall a b. (a -> Par b) -> (forall (k :: Clock). Stream k a) -> Par (Forall1 Stream b) at Productive.hs:155:10 • In the second argument of ‘(<$>)’, namely ‘_’ In a stmt of a 'do' block: Cons b <$> _ In the expression: do { (a, s') <- deStreamCons s; b <- f a; b' <- f (scar (unForall1 s')); Cons b <$> _ } • Relevant bindings include b' :: b (bound at Productive.hs:159:5) b :: b (bound at Productive.hs:158:5) s' :: Forall1 Stream a (bound at Productive.hs:157:9) (Some bindings suppressed; use -fmax-relevant-binds=N or -fno-max- relevant-binds) }}} When I set `-fno-max-relevant-binds)`, this extends with: {{{ a :: a (bound at Productive.hs:157:6) s :: forall (k :: Clock). Stream k a (bound at Productive.hs:156:9) f :: a -> Par b (bound at Productive.hs:156:7) maapM :: (a -> Par b) -> (forall (k :: Clock). Stream k a) -> Par (Forall1 Stream b) (bound at Productive.hs:156:1) take :: forall a. Int -> (forall (k :: Clock). Stream k a) -> Par [a] (bound at Productive.hs:143:1) ...and a pile more global binds... }}} I think this is not really the behavior we want. If I'm doing an Agda/Coq development, what I want is for the compiler to tell me all LOCAL bindings. Heuristically picked global bindings might be nice, but it's not a priority (after all, I probably have explicit type signatures for all of these anyway.) Thus, I propose that `-fmax-relevant-binds=N` be changed to apply to GLOBAL bindings only, and that GHC should unconditionally print all local bindings. Furthermore, I suggest that by default `-fmax-relevant-binds=0`. As a minor addendum, I don't find the context information `In the second argument of ‘(<$>)’, namely ‘_’`, etc. very useful. Just makes the message longer and harder to view. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12183> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12179: Incorrect parsing of a pattern synonym type
by GHC 24 Jun '16

24 Jun '16

#12179: Incorrect parsing of a pattern synonym type -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12108 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following definition is accepted by GHC. {{{ pattern Q :: a -> forall. (Bool -> a) pattern Q v <- (($ True) -> v) }}} What does this type signature mean? Who knows. It should be rejected for being an invalid form. Maybe see #12108 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12179> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12219: TH test failures with -fexternal-interpreter
by GHC 24 Jun '16

24 Jun '16

#12219: TH test failures with -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.0.2 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: -------------------------------------+------------------------------------- These TH tests are currently failing with -fexternal-interpreter. I need to fix these before I can enable testing of all TH tests with -fexternal- interpreter. {{{ Unexpected failures: T10697_decided_1.run T10697_decided_1 [exit code non-0] (ext-interp) T10697_decided_2.run T10697_decided_2 [exit code non-0] (ext-interp) T10697_decided_3.run T10697_decided_3 [exit code non-0] (ext-interp) T8761.run T8761 [stderr mismatch] (ext-interp) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12219> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12112: Testsuite driver links from /tmp directory to .hi and .o files in source directory
by GHC 24 Jun '16

24 Jun '16

#12112: Testsuite driver links from /tmp directory to .hi and .o files in source directory -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11980 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a clear bug, but only shows up when the source directory is not clean. Perhaps from a validate run from before the `/tmp` testsuite patch. A user might also have been running some small sample programs in the source directory manually. The testsuite driver currently matches `<testname>*`. I'm not sure if a whitelist or blacklist solution is more future proof. These are all existing filetypes in the testsuite: {{{ $ find . -name tests | xargs dir | grep -v stderr | grep -v stdout Extension Files ==================================== .def (1) .tix (1) .hspp (2) .ghci (1) .primops (1) .mix (1) .gnp (2) .so (1) .md (2) .hx (1) .sh (1) .test (1) .cpp (2) .mm (1) .gitignore (7) .m (2) .asm (4) .conf (2) .h (19) .hsc (10) .lib (2) .pkg (14) .hs-boot (49) .txt (5) .hsig (14) .cabal (37) .gml (1) .cmm (46) .sample (14) .c (66) .dat (3) .pgn (1) .stdin (8) .lhs (23) .script (318) .plt (2) .T (311) (370) . (438) .hs (5343) Total: (10370) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3