April 2018 - ghc-tickets

Re: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb
by GHC 05 Apr '18

05 Apr '18

#7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Phab:D4567 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: infoneeded => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7836#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb
by GHC 05 Apr '18

05 Apr '18

#7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Phab:D4567 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * keywords: profiling osx => profiling * version: 7.4.2 => 8.5 * differential: => Phab:D4567 Old description: > Running the attached program, compiled with "-threaded -Wall -auto-all > -caf-all -fforce-recomp -fprof-auto-top -fprof-auto-calls" - with the > following flags: +RTS -hc -hbdrag,void -RTS > > The output is as follows: > {{{ > leaks: internal error: Invalid object in processHeapClosureForDead(): 60 > (GHC version 7.4.2 for i386_apple_darwin) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > Abort trap: 6 > }}} New description: Running the attached program, compiled with `-threaded -Wall -auto-all -caf-all -fforce-recomp -fprof-auto-top -fprof-auto-calls` - with the following flags: `+RTS -hc -hbdrag,void -RTS` The output is as follows: {{{ leaks: internal error: Invalid object in processHeapClosureForDead(): 60 (GHC version 7.4.2 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 }}} -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7836#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb
by GHC 05 Apr '18

05 Apr '18

#7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Profiling | Version: 7.4.2 Resolution: | Keywords: profiling osx Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7836#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1
by GHC 05 Apr '18

05 Apr '18

#14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.2.1-rc2 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: -------------------------------------+------------------------------------- I recently noticed that the performance of `doctest` in GHC 8.2.1 can be much, much worse than in previous versions of 8.0.2. So bad, in fact, that a project with 865 `doctest` examples takes about three hours to complete in 8.2.1, whereas it would only take 8 seconds in 8.0.2. To reproduce this issue in a fairly minimal way, you can use the following script to generate a file which simulates what `doctest` is doing: {{{#!hs -- GenExample.hs module Main where import Control.Monad import System.Environment import System.Exit import System.IO main :: IO () main = do args <- getArgs case args of n:_ -> genExamples (read n) _ -> do hPutStrLn stderr "usage: runghc GenExamples.hs <num-examples>" exitWith $ ExitFailure 1 genExamples :: Int -> IO () genExamples nExamples = do putStrLn ":l Foo" ireplicateA_ nExamples genExample genExample :: Int -> IO () genExample i = putStr $ unlines [ ":m *Foo" , "example : \"expr" ++ show i ++ "\"" , "let foo = it" , "\"marker\"" , "let it = foo" ] ireplicateA_ :: Applicative m => Int -> (Int -> m a) -> m () ireplicateA_ cnt0 f = loop cnt0 0 where loop cnt n | cnt <= 0 = pure () | otherwise = f n *> (loop (cnt - 1) $! (n + 1)) }}} You'll also need this file: {{{#!hs -- Foo.hs module Foo where example :: Char example = 'a' }}} First, use `GenExample` to generate a GHCi script: {{{ $ runghc GenExample.hs 500 > Example.script }}} Now you can run the script like so (using GHCi 8.0.2 as an example): {{{ $ /opt/ghc/8.0.2/bin/ghci -ghci-script Example.script Foo.hs }}} With GHCi 8.0.2, this takes about three seconds. But with GHCi 8.2.1, this takes about 35 seconds! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14052> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #14993: QuantifiedConstraints and principal types
by GHC 04 Apr '18

04 Apr '18

#14993: QuantifiedConstraints and principal types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints, wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is not a bug but I am trying to understand the ~~implication~~ significance of `-XQuantifiedConstraints`. [https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/jfp- outsidein.pdf OutsideIn(X)] (section **2.4**) tells us `test` actually has a principle type when we have implication constraints) {{{#!hs data T :: Type -> Type where T1 :: Int -> T Bool T2 :: T a test :: (a~Bool => b~Bool) => T a -> b -> b test (T1 n) _ = n > 0 test T2 r = r }}} that subsumes {{{#!hs test1 :: T a -> a -> a test1 = test test2 :: T a -> Bool -> Bool test2 = test }}} Now that we have `-XQuantifiedConstraints` does this change the story at all, if not you can close this.. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14993> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb
by GHC 04 Apr '18

04 Apr '18

#7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Profiling | Version: 7.4.2 Resolution: | Keywords: profiling osx Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): I just hit this bug on x86_64 with GHC-8.2.2. It's a large program, so I can't provide an example, but this is still a problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7836#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15001: Add strict product field demands to lambda binders
by GHC 04 Apr '18

04 Apr '18

#15001: Add strict product field demands to lambda binders -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.5 Keywords: DmdAnal | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): D4244 | Wiki Page: -------------------------------------+------------------------------------- This is a follow-up on the first improvement in [Phab:D4244#126311]. Consider the following two functions with identical semantics: {{{ module Foo where {-# LANGUAGE BangPatterns #-} data Complex a = !a :+ !a foo :: Complex Double -> Int -> Complex Double foo !x 0 = x foo (a :+ b) _ = b :+ a bar :: Complex Double -> Int -> Complex Double bar x 0 = x bar (a :+ b) _ = b :+ a }}} In the corresponding simplified Core, `x` gets strictness `S(SS)` for `foo`, but only `S` for `bar`. We could do better by looking at `x`s type and see that its a product type with strict fields. This is because currently only case binders get [https://github.com/ghc/ghc/blob/72b5f649ede82ab3bb429aa72ee1c572f415b0eb/co… special treatment] for strict product fields through `addDataConStrictness`. This ticket tracks if the same is worthwhile for lambda binders, as in `bar` above. Note that intuitively, this shouldn't make any difference because when we eventually unleash an `S` demand on a `Complex` constructor, we add `seqDmd` on strict fields anyway, amounting to `S(SS)`. So this is only a matter of recording things early because some parts of the analysis code might not be smart enough to add strict field demands by themselves. Also note that this doesn't touch impliciations on usage analysis at all, where unleashing the same `seqDmd` twice might mean we accidentally make some product field lose its single-entrieness. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15001> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12938: Polykinded associated type family rejected on false pretenses
by GHC 04 Apr '18

04 Apr '18

#12938: Polykinded associated type family rejected on false pretenses -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I say {{{ class HasRep a where type Rep a :: TYPE r }}} I get {{{ • Kind variable ‘r’ is implicitly bound in datatype ‘Rep’, but does not appear as the kind of any of its type variables. Perhaps you meant to bind it (with TypeInType) explicitly somewhere? Type variables with inferred kinds: a • In the class declaration for ‘HasRep’ }}} This definition should be accepted, though, as `r` is just an invisible parameter to the associated type family. (I don't know how ''useful'' this is, but it's not bogus.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12938> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12742: Instantiation of invisible type family arguments is too eager
by GHC 04 Apr '18

04 Apr '18

#12742: Instantiation of invisible type family arguments is too eager -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | 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: -------------------------------------+------------------------------------- This module looks, to me, like it should be accepted: {{{ {-# LANGUAGE TypeInType, RankNTypes, TypeFamilies #-} module Bug where import Data.Kind type family F :: forall k2. (k1, k2) data T :: (forall k2. (Bool, k2)) -> Type type S = T F }}} But it's not. The problem is that `TcHsType.handle_tyfams` eagerly instantiates ''all'' invisible arguments to a type family at every occurrence. Instead, it should instantiate only those that are counted in the TF's arity -- that is, those "before the colon". Will fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14764: Make $! representation-polymorphic
by GHC 04 Apr '18

04 Apr '18

#14764: Make $! representation-polymorphic -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4382 | Wiki Page: -------------------------------------+------------------------------------- Currently, {{{#!hs ($) :: forall r a (b :: TYPE r). (a -> b) -> a -> b }}} but {{{#!hs ($!) :: (a -> b) -> a -> b }}} It seems fairly obvious that we should generalize `($!)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14764> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2