August 2017 - ghc-tickets

Re: [GHC] #7647: UNPACK polymorphic fields
by GHC 12 Aug '17

12 Aug '17

#7647: UNPACK polymorphic fields -------------------------------------+------------------------------------- Reporter: liyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3990 #9655 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ethercrow): * cc: ethercrow (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7647#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 11 Aug '17

11 Aug '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): Not only string literals could benefit from ByteArray# literals: Integer/BigNats could too! Currently big integer literals are desugared into a list of `Int` chunks. With ByteArray# literals we could represent them directly as a constant! Whats the status on this ticket? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:77> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14104: Pattern synonyms work where constructors fail
by GHC 10 Aug '17

10 Aug '17

#14104: Pattern synonyms work where constructors fail -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- This may be a bug. Taken from [https://www.reddit.com/r/haskell/comments/6so95h/why_do_pattern_synonyms_wo… reddit thread]: {{{#!hs {-# LANGUAGE DataKinds, FlexibleInstances, GADTs, MultiParamTypeClasses, PatternSynonyms, TupleSections, TypeFamilies, TypeFamilyDependencies, TypeOperators, ViewPatterns #-} -- ... type family Sum (ts :: [*]) = (t :: *) | t -> ts where Sum (t ': ts) = Either t (Sum ts) Sum '[] = Void pattern At :: (KnownNatural n, Index n ts) => SNatural n -> (ts !! n) -> Sum ts pattern At sn t <- (at -> Just (sn, t)) where At = toSum at :: (KnownNatural n, Index n ts) => Sum ts -> Maybe (SNatural n, ts !! n) at = fmap (sn,) . ofSum sn where sn = knownNatural class Index (n :: Natural) (ts :: [*]) where type (!!) ts n :: * toSum :: SNatural n -> (ts !! n) -> Sum ts ofSum :: SNatural n -> Sum ts -> Maybe (ts !! n) instance Index n ts => Index ('Succ n) (t ': ts) where type (!!) (t ': ts) ('Succ n) = ts !! n toSum (SSucc sn) = Right . toSum sn ofSum (SSucc sn) = either (const Nothing) (ofSum sn) instance Index 'Zero (t ': ts) where type (!!) (t ': ts) 'Zero = t toSum SZero = Left ofSum SZero = either Just (const Nothing) data Natural = Zero | Succ Natural data SNatural (n :: Natural) where SZero :: SNatural 'Zero SSucc :: SNatural n -> SNatural ('Succ n) class KnownNatural (n :: Natural) where knownNatural :: SNatural n instance KnownNatural 'Zero where knownNatural = SZero instance KnownNatural n => KnownNatural ('Succ n) where knownNatural = SSucc knownNatural }}} Using `SZero`, `SSucc SZero`, ... fails {{{#!hs type Trit = Sum '[(), (), ()] fromTrit :: Trit -> Int fromTrit (At SZero ()) = 0 fromTrit (At (SSucc SZero) ()) = 1 fromTrit (At (SSucc (SSucc SZero)) ()) = 2 }}} but making pattern synonyms succeeds {{{#!hs pattern S0 :: SNatural 'Zero pattern S0 = SZero pattern S1 :: SNatural ('Succ 'Zero) pattern S1 = SSucc S0 pattern S2 :: SNatural ('Succ ('Succ 'Zero)) pattern S2 = SSucc S1 type Trit = Sum '[(), (), ()] fromTrit :: Trit -> Int fromTrit (At S0 ()) = 0 fromTrit (At S1 ()) = 1 fromTrit (At S2 ()) = 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14104> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14095: Improve parallelism in --make mode
by GHC 10 Aug '17

10 Aug '17

#14095: Improve parallelism in --make mode -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- Currently, GhcMake.parUpsweep compiles modules in parallel, with each module waiting for all of it's dependencies to complete before proceeding. Parallelism is constrained by the -j flag, which limits the number of modules that may be compiled simultaneously. When multiple modules could be compiled next, ties are broken by a race to claim a semaphore. This ticket is about improving this parallelism, both by making it more finely-grained, and by more intelligently scheduling the next module to compile. This allows, for example, for code generation of modules compiled early to be delayed, so that other modules can be typechecked and simplified, unblocking their dependencies. I have a patch implementing the design described below, and I hope to have it on phab this week. It will be very much still a work in progress, however, some initial benchmarking suggests some quite good results, so I would very much appreciate feedback and help at this stage. The unit of operation of parUpsweep is a MakeTask, defined with some companion types as: {{{ data BuildModule = BuildModule ModuleName IsBoot data MakePipeline = MP_Parse | MP_Typecheck | MP_Simplify | MP_CodeGen data MakeTask = MakeTask BuildModule MakePipeline }}} As a module compiles, it starts parsing, then at the completion of hscParse', it moves to typechecking. Then, after desugaring it moves to simplifying, then after hscSimplify' moves to codegen. Note that a module can be parsed independently of it's dependencies. It can, in principle (I claim!), be typechecked once it's dependencies have been typechecked, and be simplified once it's dependencies have been simplified. It can be codegened independently of it's dependencies. In HscEnv, we store four IO actions in the following data type, {{{ data HscYield = HscYield { yieldParsedSource :: HscEnv -> ModSummary -> HsParsedModule -> IO () , yieldTypecheckedInterface :: HscEnv -> ModSummary -> ModIface -> Maybe ModDetails -> IO HomeModInfo , yieldSimplifiedInterface :: HscEnv -> ModSummary -> ModIface -> Maybe ModDetails -> IO HomeModInfo , awaitDependencyInterfaces :: HscEnv -> ModSummary -> IO () } }}} The first three members are called when a MakePipeline stage is complete. The fourth must be called to ensure all a module's dependent modules are present in the home package table. This is necessary at least during some codepaths in recompilation avoidance and safe haskell checking. All these IO actions will block, and return only once the next MakePipeline stage for that module has been scheduled to run. Calls to these functions are sprinkled through HscMain in strategic locations. We also change HscEnv.hsc_HPT to be an IORef HomePackageTable. I do expect this to be controversial, and even potentially unacceptable, and there are potentially alternate implementations on which I will not elaborate here. Note that responsibility for adding an interface to the home package table is on the implementer of yieldTypecheckedInterface and yieldSimplifiedInterface. In Ghc.parUpsweep we pre-compute a graph with nodes of MakeTasks and edges dependencies on other MakeTasks. We maintain a priority queue of MakeTasks whose dependencies are satisfied, where the priority is loosely an estimate of the work unblocked by completing that task. Whenever a MakeTask completes (and parUpsweep is notified via a call to a yield... function described above), the next MakeTask is dequeued from the priority queue and allowed to continue. There is some complication in the transition from typechecking to simplifying, and in ensuring the correct information is present in the home package table at the right time. Perhaps it is better to treat this as a single pipeline stage, and indeed, perhaps parsing as a separate pipeline stage does not pull its weight. I believe the split between simplify and codegen is where the majority of the benefit lies. Nevertheless, as is, it is working, so I must at least offer the full idea for consideration. I do understand that this will be difficult to understand or comment on without the code, and I'll endeavour to get it on phab as soon as I can, along with some benchmarks to motivate this change. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14095> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14102: panic! (the 'impossible' happened)
by GHC 09 Aug '17

09 Aug '17

#14102: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: pmckelvy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (GHC version 8.0.2 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] action_a1Ei :: t_a1Eh[tau:1] (CHoleCan: action)} ******* code ******** import Data.Char import Data.List data InvoiceStruct = InvoiceStruct { total :: Int , shippedItemCount :: Int } deriving (Show) invoice :: InvoiceStruct -> String -> Int -> InvoiceStruct invoice i comp val = (action) i[total] val -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14102> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13615: Wrong results from what supposed to be pure function with presense of parallel evaluation
by GHC 09 Aug '17

09 Aug '17

#13615: Wrong results from what supposed to be pure function with presense of parallel evaluation -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Mostly self contained sample - only depends on base, deepseq and locally provided hashable and unordered-containers. No unsafePtrEq involved, but unsafeThaw/Freese is - affected function uses `foldl'` to insert stuff into hashmap - I don't think there's a way to obtain multiple references to the same map. Making arguments strict or rnf'ing them doesn't help. Issue is reproduceable with HEAD with -O0 but not with O2. in ghc 8.0.2 and 7.10.1 it's reproduceable with -O2 as well. {{{ sum (map snd xs) = map snd (toList $ fromListWith (+) xs) }}} ^ this statement fails to hold when xs contains stuff with memocombinators and parallel evaluation from evaluation strategies I found which inplace update needs to be replaced with copy and update to make things work - bug is fixed after changing unsafeInsertWith, BitmapIndexed branch: {{{ - A.unsafeUpdateM ary i st' - return t + let ary' = A.update ary i st' + return $ BitmapIndexed b ary' }}} Steps: clone this: {{{ https://github.com/pacak/cuddly-bassoon }}} {{{ stack build }}} {{{ ./.stack-work/install/x86_64-linux/ghc-8.0.2/8.0.2/bin/gamebooksolver- solvebook02 }}} Last command will either finish successfully printing `"solving\n0.0"` or will die with `error` in `src/Solver.hs` `regroup` function. To reproduce the problem computer must have at least 3 CPUs, running with +RTS -N1 or -N2 "fixes" the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13615> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 57

[GHC] #8147: Exponential behavior in instance resolution on fixpoint-of-sum
by GHC 07 Aug '17

07 Aug '17

#8147: Exponential behavior in instance resolution on fixpoint-of-sum -------------------------+------------------------------------------------- Reporter: | Owner: jkoppel | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: performance, | Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Doing instance resolution on a fixpoint-of-sum type takes a very long time. This is possibly the same issue as issue #5642. These are the numbers I see for various n: {{{ 10 : 0.329s 20 : 0.479s 40 : 0.935s 80 : 2.821s 160 : 11.694s 320 : 1m30.39s 640: Ran for over 1 hour without terminating }}} This uses a couple of attached support files. Apologies for not being able to reduce further. {{{ -- Test.hs {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, UndecidableInstances, OverlappingInstances, TypeOperators, DeriveFunctor, TemplateHaskell #-} module Test where import Control.Monad import Lib import TH {- With n=3, produces data X1 e = X1 e deriving (Functor) data X2 e = X2 e deriving (Functor) data X3 e = X3 e deriving (Functor) type X = X1 :+: X2 :+: X3 -} $(let n = 320 in liftM concat $ sequence [liftM concat $ mapM mkDec $ map (('X':).show) [1..n] , makeSumType "X" (map (('X':).show) [1..n])]) data Y0 e = Y0 e deriving ( Functor ) type X' = Y0 :+: X class Lift f g where lift' :: f (Fix g) -> Fix g instance (Lift f g, Lift f' g) => Lift (f :+: f') g where lift' x = case x of L e -> lift' e R e -> lift' e instance (Functor f, f :<: g) => Lift f g where lift' = In . inj cata :: (Functor f) => (f a -> a) -> Fix f -> a cata f = f . fmap (cata f) . out lift :: Fix X -> Fix X' lift = cata lift' }}} Virtually all the time is spent in compiling lift. For example, with n=640, commenting out lift makes it compile in around 2 seconds. Interestingly, when I add the following code, compilation times only increase by 10-20%. In the original code where I encountered this issue, doing so doubles compilation time. {{{ instance Lift Y0 X where lift' = undefined lower :: Fix X' -> Fix X lower = cata lift' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14097: -ddump-json doesn't interact as expected with -ddump-to-file
by GHC 07 Aug '17

07 Aug '17

#14097: -ddump-json doesn't interact as expected with -ddump-to-file -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: JSON | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Usually with dump flags, if you set `ddump-to-file` then the dumped file will be outputted in the current directory if `-dumpdir` or `-ddump-file- prefix` is not set. This doesn't work with `-ddump-json`, if you do not specify `-ddump-file-prefix` then the output is always on stdout. Clearly stated, here are the two problems which I think have the same solution. 1. `-ddump-to-file -ddump-json` should output a file in the currect directory. 2. `-ddump-to-file -ddump-json` does not respect `-dumpdir` It seems that a stale set of DynFlags is used to direct the output of `-ddump-json`. The relevant function is `DynFlags.jsonLogFinaliser`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14097> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13190: Add a flag to dump compiler output as JSON
by GHC 07 Aug '17

07 Aug '17

#13190: Add a flag to dump compiler output as JSON -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 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): Phab:D3010 | Wiki Page: -------------------------------------+------------------------------------- This ticket is to track the `-ddump-json` flag which is implemented by Phab:D3010. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13190> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11196: TypeInType performance regressions
by GHC 07 Aug '17

07 Aug '17

#11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- This ticket is to track the handful of performance regressions seen with the addition of `TypeInType`. It is quite possibly a good idea to break these out into separate tickets, but until we investigate, they're all bundled here. The regressions are: * T3064, bytes allocated up by 14.9% (will update description) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11196> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21