April 2016 - ghc-tickets

[GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine
by GHC 04 Dec '18

04 Dec '18

#9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------+------------------------------------------------- Reporter: | Owner: carter | Status: new Type: bug | Milestone: Priority: high | Version: 7.8.2 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- im seeing slowdowns in parallel builds of a (simple!!) 6 module project when I build it on a 40 core server i'm using for work. for any given ghc invocation with -jn, once n>10, i start to see a super linear slow down as a function of n heres some basic numbers at -j1 0m2.693s at -j4 0m2.507s at -j10 0m2.763s at -j25 0m12.634s at -j30 : 0m39.154s at -j40 : 0m57.511s at -j60 : 2m21.821s these timings are another 2-4x worse if ghc is invoked indirectly via cabal-install / setup.hs according to the linux utility latencytop, 100% of ghc's cpu time was spent on user-space lock contention when I did the -j40 invocation. the timing in the -j40 case stayed the same even when ghc was also passed -O0 (and -fforce-recomp to ensure it did the same ) a bit of experimentation makes me believe that in *ANY* cabalized project on a 40 core machine will exhibit this perf issue. cabal clean ; cabal configure --ghc-options="-j" ; cabal build -j1 should be enough to trigger the lock contention. That said, I'll try to cook up a minimal repro that i can share the source for post haste. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9221> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 90

[GHC] #10739: Resuscitate the humble ticky-ticky profiler
by GHC 04 Dec '18

04 Dec '18

#10739: Resuscitate the humble ticky-ticky profiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | 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 Revisions: | -------------------------------------+------------------------------------- The [https://ghc.haskell.org/trac/ghc/wiki/Debugging/TickyTicky ticky- ticky profiler] is known to be quite bit-rotted. Indeed there currently isn't even a definitive list of the counters, much less what they counter and whether they are still accurate. That being said, it can be quite useful and is worth putting effort into bringing back up to grade. There are a few things that need to be done here, 1. Collect a list of the existing counters 2. Work out what they are supposed to be measuring 3. Decide which still have a chance of being useful and accurate 4. ??? 5. Profile! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10930: missing empty-Enumeration warning for `Natural`
by GHC 03 Dec '18

03 Dec '18

#10930: missing empty-Enumeration warning for `Natural` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.0.1 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: #7881, #10929 Differential Rev(s): | -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10930> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9505: Bounded instance for Word (and possibly others) uses unboxed literals
by GHC 03 Dec '18

03 Dec '18

#9505: Bounded instance for Word (and possibly others) uses unboxed literals -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- There's a comment above saying GHC won't optimise. I think since 7.8 they are unboxed by default, so that comment and the explicit constructors can be removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9505> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8043: Feature Request : Qualified module exports
by GHC 01 Dec '18

01 Dec '18

#8043: Feature Request : Qualified module exports ------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I quite like the practice of using `-XNoImplicitPrelude` and then defining my own (often per-project) Prelude doing things like: {{{ module MyProject.Prelude ( module P ) import Data.Text as P (Text) import Prelude as P hiding (head, init, tail, last) }}} As an extension to the above idea, I would like to add qualified module exports defined so that I can do this: {{{ module MyProject.Prelude ( module P , qualified module T ) import Data.Text as P (Text) import Prelude as P hiding (head, init, tail, last) import qualified Data.Text as T }}} so that any file which imports `MyProject.Prelude` will then have all the identifiers that they would normally get if they did: {{{ import qualified Data.Text as T }}} Is this something that would have to go through the Haskell Next procedure? If so, how does one get that kicked off? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8043> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #8177: Roles for type families
by GHC 29 Nov '18

29 Nov '18

#8177: Roles for type families ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Now that we have [wiki:Roles roles], it might be helpful to be able to give a role signature for a data/type family. At the moment, data/type family constructors have all parameters conservatively assigned to be role `N`. Thus {{{ data family D a -- Parameter conservatively assumed to be N class C a where op :: D a -> a instance C Int where .... newtype N a = MkN a deriving( C ) -- Rejected }}} The generalised-newtype-deriving clause `deriving( C )` is rejected because `D` might use its parameter at role `N` thus: {{{ data instance D [b] = MkD (F b) -- F is a type function }}} It would be strictly more expressive if we could * '''Declare''' the roles of D's arguments (as we can declare their kinds). E.g. {{{ data family D a@R }}} * '''Check''' that each family instance obeys that role signature. E.g. given the preceding role signature, reject this instance: {{{ data instance D [b] = MkD (F b) -- F is a type function }}} I think there is no technical difficulty here. Just a question of doing it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8177> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 41

[GHC] #10844: CallStack should not be inlined
by GHC 26 Nov '18

26 Nov '18

#10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | 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 Revisions: | -------------------------------------+------------------------------------- The use of CallStack based error messages (since changeset:6740d70d95cb) has led to some code size increase, and I believe this needs to be improved. While investigating the #10788, I was looking at the core produced by that code, and I found this in the code: {{{ -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main17 :: [Char] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 100 0}] Main.main17 = unpackCString# "vecto_20t0fI93Jj9LUbaZg6e04I"# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main16 :: [Char] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 110 0}] Main.main16 = unpackCString# "Data.Vector.Primitive.Mutable"# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main15 :: [Char] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 120 0}] Main.main15 = unpackCString# "./Data/Vector/Primitive/Mutable.hs"# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main14 :: Int [GblId, Caf=NoCafRefs, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] Main.main14 = I# 97# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main13 :: Int [GblId, Caf=NoCafRefs, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] Main.main13 = I# 16# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main12 :: Int [GblId, Caf=NoCafRefs, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] Main.main12 = I# 21# -- RHS size: {terms: 8, types: 0, coercions: 0} Main.main11 :: SrcLoc [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 80}] Main.main11 = SrcLoc Main.main17 Main.main16 Main.main15 Main.main14 Main.main13 Main.main14 Main.main12 }}} This is clearly a CallStack from a library, and there is no point in copying that into the (every?) use of wherever that came from, as it will only increase code size and slow down compilation. I don’t know how to fix it, though. Float out CallStacks more aggressively? Or is the problem that unfoldings are recorded before that can happen? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10844> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #10803: New TypeSignatureSections extension
by GHC 26 Nov '18

26 Nov '18

#10803: New TypeSignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 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 Revisions: | -------------------------------------+------------------------------------- = Preliminary specification Have - `(::` ''type'' `)` be syntax sugar for - `(\x -> x ::` ''type'' `)` This new syntax extension is enabled via a new `TypeSignatureSections` language pragma, i.e. {{{#!hs {#- LANGUAGE TypeSignatureSections #-} }}} TODO: formalise this a bit more -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10803> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition)
by GHC 22 Nov '18

22 Nov '18

#8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition) ------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- == Abstract == Hi! I'm writing a compiler, which produces Haskell code. I've discovered it is impossible to keep currently used features / logic using GHC 7.7 instead of 7.6 Below is more detailed description of the problem: == The idea == I'm writing a [DSL][1], which compiles to Haskell. Users of this language can define own immutable data structures and associated functions. By associated function I mean a function, which belongs to a data structure. For example, user can write (in "pythonic" pseudocode): {{{#!python data Vector a: x,y,z :: a def method1(self, x): return x }}} (which is equivalent to the following code, but shows also, that associated functions beheva like type classes with open world assumption): {{{#!python data Vector a: x,y,z :: a def Vector.method1(self, x): return x }}} In this example, `method1` is a function associated with `Vector` data type, and can be used like `v.testid(5)` (where `v` is instance of `Vector` data type). I'm translating such code to Haskell code, but I'm facing a problem, which I'm trying to solve for a long time. == The problem == I'm trying to move the code from GHC 7.6 over GHC 7.7. The code works perfectly under GHC 7.6, but does not under GHC 7.7. I want to ask you how can I fix it to make it working in the new version of the compiler? == Example code == Lets see a simplified version of generated (by my compiler) Haskell code: {{{#!haskell {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FunctionalDependencies #-} import Data.Tuple.OneTuple ------------------------------ -- data types ------------------------------ data Vector a = Vector {x :: a, y :: a, z :: a} deriving (Show) -- the Vector_testid is used as wrapper over a function "testid". newtype Vector_testid a = Vector_testid a ------------------------------ -- sample function, which is associated to data type Vector ------------------------------ testid (v :: Vector a) x = x ------------------------------ -- problematic function (described later) ------------------------------ testx x = call (method1 x) $ OneTuple "test" ------------------------------ -- type classes ------------------------------ -- type class used to access "method1" associated function class Method1 cls m func | cls -> m, cls -> func where method1 :: cls -> m func -- simplified version of type class used to "evaluate" functions based on -- their input. For example: passing empty tuple as first argument of `call` -- indicates evaluating function with default arguments (in this example -- the mechanism of getting default arguments is not available) class Call a b where call :: a -> b ------------------------------ -- type classes instances ------------------------------ instance (out ~ (t1->t1)) => Method1 (Vector a) Vector_testid out where method1 = (Vector_testid . testid) instance (base ~ (OneTuple t1 -> t2)) => Call (Vector_testid base) (OneTuple t1 -> t2) where call (Vector_testid val) = val ------------------------------ -- example usage ------------------------------ main = do let v = Vector (1::Int) (2::Int) (3::Int) -- following lines equals to a pseudocode of ` v.method1 "test" ` -- OneTuple is used to indicate, that we are passing single element. -- In case of more or less elements, ordinary tuples would be used. print $ call (method1 v) $ OneTuple "test" print $ testx v }}} The code compiles and works fine with GHC 7.6. When I'm trying to compile it with GHC 7.7, I'm getting following error: {{{ debug.hs:61:10: Illegal instance declaration for ‛Method1 (Vector a) Vector_testid out’ The liberal coverage condition fails in class ‛Method1’ for functional dependency: ‛cls -> func’ Reason: lhs type ‛Vector a’ does not determine rhs type ‛out’ In the instance declaration for ‛Method1 (Vector a) Vector_testid out’ }}} The error is caused by new rules of checking what functional dependencies can do, namely `liberal coverage condition` (as far as I know, this is `coverage condition` relaxed by using `-XUndecidableInstances`) == Some attemps to fix the problem == I was trying to overcome this problem by changing the definition of `Method1` to: {{{#!haskell class Method1 cls m func | cls -> m where method1 :: cls -> m func }}} Which resolves the problem with functional dependencies, but then the line: {{{#!haskell testx x = call (method1 x) $ OneTuple "test" }}} is not allowed anymore, causing a compile error (in both 7.6 and 7.7 versions): {{{ Could not deduce (Method1 cls m func0) arising from the ambiguity check for ‛testx’ from the context (Method1 cls m func, Call (m func) (OneTuple [Char] -> s)) bound by the inferred type for ‛testx’: (Method1 cls m func, Call (m func) (OneTuple [Char] -> s)) => cls -> s at debug.hs:50:1-44 The type variable ‛func0’ is ambiguous When checking that ‛testx’ has the inferred type ‛forall cls (m :: * -> *) func s. (Method1 cls m func, Call (m func) (OneTuple [Char] -> s)) => cls -> s’ Probable cause: the inferred type is ambiguous }}} It is also impossible to solve this issue using type families (as far as I know). If we replace `Method1` type class and instances with following code (or simmilar): {{{#!haskell class Method1 cls m | cls -> m where type Func cls method1 :: cls -> m (Func cls) instance Method1 (Vector a) Vector_testid where type Func (Vector a) = (t1->t1) method1 = (Vector_testid . testid) }}} We would get obvious error `Not in scope: type variable ‛t1’`, because type families does not allow to use types, which does not appear on LHS of type expression. == The final question == How can I make this idea work under GHC 7.7? I know the new `liberal coverage condition` allows GHC devs make some progress with type checking, but it should somehow be doable to port idea working in GHC 7.6 over never compiler version. (without forcing user of my DSL to introduce any further types - everything so far, like type class instances, I'm genarating using Template Haskell) Maybe is there a way to indroduce an extension, which will disable liberal coverage condition in such situations? There is also a StackOverflow discussion available, here: http://stackoverflow.com/questions/20778588/liberal-coverage-condition- introduced-in-ghc-7-7-breaks-code-valid-in-ghc-7-6 [1]: http://en.wikipedia.org/wiki/Domain-specific_language -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8634> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 71

[GHC] #10445: Wrong stack space size when using -Ksize
by GHC 19 Nov '18

19 Nov '18

#10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- After compiling the first example in https://wiki.haskell.org/Performance/Accumulating_parameter: {{{ $ cat Test.hs len :: [a] -> Int len [] = 0 len (x:xs) = len xs + 1 main :: IO () main = print $ len [1..1000000] }}} {{{ $ ghc Test.hs -rtsopts }}} and running {{{ ./Test +RTS -K10K }}} GHC 7.6.3 reports {{{ Stack space overflow: current size 10240 bytes. }}} GHC 7.8.4 reports {{{ Stack space overflow: current size 33632 bytes. }}} and GHC 7.10.1 reports {{{ Stack space overflow: current size 99136 bytes. }}} GHC 7.8.3 and 7.10.1 report an incorrect stack space size. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10445> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14