September 2018 - ghc-tickets

[GHC] #10990: Checking whether a default declaration is an instance of a defaultable typeclass is broken
by GHC 26 Sep '18

26 Sep '18

#10990: Checking whether a default declaration is an instance of a defaultable typeclass is broken -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (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: -------------------------------------+------------------------------------- In TcDefaults.hs, `tcDefaults` is supposed to check whether the supplied default type is an instance o `Num` or `IsString` (note the lack of extended defaults here, so this has been broken for quite some time). Following the code we can see that `simplifyDefault` in TcSimplify.hs calls `reportAllUnsolved` and it does report the error -- with typechecker tracing on we see {{{ Adding error: <interactive>:19:1: error: No instance for (Num []) arising from a 'default' declaration When checking the types in a default declaration }}} But typechecking never actually fails, so it returns `Just ()` regardless and the error gets swallowed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10990> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15673: ghc: panic! (the 'impossible' happened)
by GHC 26 Sep '18

26 Sep '18

#15673: ghc: panic! (the 'impossible' happened) --------------------------------------+--------------------------------- Reporter: mcmayer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.4 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- The following few lines produce a GHC panic: {{{#!hs module Main where import Data.Bits (shift) badOne :: [Int] -> Integer badOne is = sum $ zipWith (\n _->shift 1 n) (enumFrom 0) is main = return () :: IO () }}} The function is stripped down as much as possible, it doesn't perform anything all to meaningful anymore. The error message is: {{{#!bash ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): heap overflow }}} All else is off-the-shelf stack lts-12.10 via {{{#!bash stack new bad-one simple }}} Tested on Mac OS X and Debian. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15673> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15666: Dependent type synonym in recursive type family causes GHC to panic
by GHC 25 Sep '18

25 Sep '18

#15666: Dependent type synonym in recursive type family causes GHC to panic -------------------------------------+------------------------------------- Reporter: tydeu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- = Background I had written the following code in Haskell (GHC): {{{#!hs {-# LANGUAGE NoImplicitPrelude, TypeInType, PolyKinds, DataKinds, ScopedTypeVariables, TypeFamilies, UndecidableInstances #-} import Data.Kind(Type) data PolyType k (t :: k) type Wrap (t :: k) = PolyType k t type Unwrap pt = (GetType pt :: GetKind pt) type family GetKind (pt :: Type) :: Type where GetKind (PolyType k t) = k type family GetType (pt :: Type) :: k where GetType (PolyType k t) = t }}} The intention of this code is to allow me to wrap a type of an arbitrary kind into a type (namely `PolyType`) of a single kind (namely `Type`) and then reverse the process (i.e. unwrap it) later. = Problem I wanted to define a function that would recursively operate on a composite type like so: {{{#!hs data Composite :: a -> b -> Type type family RecursiveWrap (expr :: exprK) where RecursiveWrap (Composite a b) = Wrap (Composite (Unwrap (RecursiveWrap a)) (Unwrap (RecursiveWrap b))) RecursiveWrap x = Wrap x }}} However, the above definition causes GHC to panic: {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-mingw32): cyclic evaluation in fixIO }}} = Ideas If we inline the the `Unwrap` synoynm into the defintion of the type family above like so: {{{#!hs type family RecursiveWrap expr where RecursiveWrap (Composite a b) = Wrap (Composite (GetType (RecursiveWrap a) :: GetKind (RecursiveWrap a)) (GetType (RecursiveWrap a) :: GetKind (RecursiveWrap a)) ) RecursiveWrap x = Wrap x }}} GHC instead simply produces an error: {{{ * Type constructor `RecursiveWrap' cannot be used here (it is defined and used in the same recursive group) * In the first argument of `GetKind', namely `(RecursiveWrap a)' In the kind `GetKind (RecursiveWrap a)' In the first argument of `Composite', namely `(GetType (RecursiveWrap a) :: GetKind (RecursiveWrap a))' }}} As such, I suspect this has to do with the recursive type family appearing in the kind signature when the `Unwrap` type synonym is expanded. However, it strikes me as odd that even the above code errors. Since with the `UndecidableInstances` extension turned on, I think that I should be able to write recursive type families like the above. Especially given that the above family would not loop indefinitely and thus be reducible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15666> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12848: Reduce long-term memory usage of GHCi
by GHC 25 Sep '18

25 Sep '18

#12848: Reduce long-term memory usage of GHCi ---------------------------------------+-------------------------- Reporter: arybczak | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+-------------------------- If you take moderately sized Haskell project (let's use lens as an example) and decide to work with it using `cabal repl`, memory usage of GHCi becomes a bit problematic after a few code reloads. I compared 7.10.3 and 8.0.1 using the following steps: 1. Start GHCi with `cabal repl`. 2. Wait for all modules to load, check memory usage with `htop`. 3. Issue `find . -name '*.hs' -exec touch {} +` in src directory. 4. Issue `:r` in GHCi so it reloads all modules. 5. Repeat (3) and (4) four more times. Results: '''GHC 7.10.3''' * After `cabal repl`: 874MB * After reloading all modules (1st): 1304MB * After reloading all modules (2nd): 1763MB * After reloading all modules (3rd): 2216MB * After reloading all modules (4th): 2672MB * After reloading all modules (5th): 3121MB Basically, every time modules are reloaded memory usage increases by ~450MB, which is definitely not fun. '''GHC 8.0.1''' * After `cabal repl`: 1322MB * After reloading all modules (1st): 2144MB * After reloading all modules (2nd): 2201MB * After reloading all modules (3rd): 2208MB * After reloading all modules (4th): 2212MB * After reloading all modules (5th): 2213MB Here the initial memory usage is much higher as with 7.10.3 and there is a sharp increase after first full reload, but then it more or less plateaus. I presume this change is the result of 6ae616f5be1db6da8bc0c5e36736a76cfea46844 - upfront memory usage is probably higher due to more things being forced (and the fact that memory usage doesn't increase indefinitely is great). However, I'm still concerned about the spike after the first reload - would it be possible to get rid of (or at least decrease) it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees"
by GHC 24 Sep '18

24 Sep '18

#14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- = The basic Ideas Currently GHC uses Augustssons algorithm for pattern matching which was published in 85 which works fine for many cases. However there has been research on how to do better than that for a while now. Most notably by Maranget in "Compiling Pattern Matching to Good Decision Trees". I plan to look into applying his ideas to GHC for my undergraduate thesis. Thanks to imprecise exceptions we should be able to reorder argument evaluation as long as this doesn't make our programs more strict. Proofing that is high on my bucket list but hasn't been done yet. = Pros and Cons **Advantages** would be: * It should lead to equal or better code for the vast majority of patterns. * It might reduce compile times for cases were we can desugar directly to good code. **Disadvantages**: * Desugaring gets more complex. It' obvious that since the underlying algorithm is more complex the desugarer would also grow in complexity in accordance. It is hard to say in advance how much of a difference it will make but I hope it won't be too bad. Depending on the runtime of the new algorithm compared to the old one this might also speed up compilation for cases where the old algorithm generated code that had to be heavily optimized by the simplifier. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14201> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #8578: Improvements to SpinLock implementation
by GHC 24 Sep '18

24 Sep '18

#8578: Improvements to SpinLock implementation ------------------------------------+------------------------------------- Reporter: parcs | Owner: parcs Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | 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: | ------------------------------------+------------------------------------- The SpinLock implementation has a number of deficiencies. Here is a pair of patches that improves its implementation. Let me know what you think. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8578> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10193: TypeRep Show instance doesn't add parens around type operators
by GHC 24 Sep '18

24 Sep '18

#10193: TypeRep Show instance doesn't add parens around type operators -------------------------------------+------------------------------------- Reporter: | Owner: pawel.nowak | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1-rc3 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: Incorrect result Keywords: | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following code {{{#!hs {-# LANGUAGE AutoDeriveTypeable #-} {-# LANGUAGE TypeOperators #-} import Data.Typeable data a :*: b = Pair a b main = print (typeOf (Pair 'a' 'b')) }}} prints {{{#!hs :*: Char Char }}} which is not valid Haskell. I belive it should print {{{#!hs (:*:) Char Char }}} In my particular case I am using Hint to interpret a type involving type operators. Hint uses showed TypeRep as a type annotation: {{{#!hs let type_str = show $ Data.Typeable.typeOf wit ... let expr_typesig = concat [parens e, " :: ", type_str] }}} What results in a parse error. I can write a patch if someone confirms that's the desired behavior and doesn't break anything. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10193> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections
by GHC 24 Sep '18

24 Sep '18

#7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15665 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: => #15665 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7670#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15668: Allocations values for some compile tests are way too hight
by GHC 23 Sep '18

23 Sep '18

#15668: Allocations values for some compile tests are way too hight ----------------------------------------+--------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- These tests have way too high allocation counts. {{{ bytes allocated value is too high: Expected T12425(optasm) bytes allocated: 139100464 +/-5% Lower bound T12425(optasm) bytes allocated: 132145440 Upper bound T12425(optasm) bytes allocated: 146055488 Actual T12425(optasm) bytes allocated: 149370944 Deviation T12425(optasm) bytes allocated: 7.4 % *** unexpected stat test failure for T12425(optasm) bytes allocated value is too high: Expected MultiLayerModules(normal) bytes allocated: 5619893176 +/-10% Lower bound MultiLayerModules(normal) bytes allocated: 5057903858 Upper bound MultiLayerModules(normal) bytes allocated: 6181882494 Actual MultiLayerModules(normal) bytes allocated: 6693788656 Deviation MultiLayerModules(normal) bytes allocated: 19.1 % *** unexpected stat test failure for MultiLayerModules(normal) bytes allocated value is too high: Expected T11303b(normal) bytes allocated: 54373936 +/-10% Lower bound T11303b(normal) bytes allocated: 48936542 Upper bound T11303b(normal) bytes allocated: 59811330 Actual T11303b(normal) bytes allocated: 62015072 Deviation T11303b(normal) bytes allocated: 14.1 % *** unexpected stat test failure for T11303b(normal) bytes allocated value is too high: Expected T12234(optasm) bytes allocated: 79889200 +/-5% Lower bound T12234(optasm) bytes allocated: 75894740 Upper bound T12234(optasm) bytes allocated: 83883660 Actual T12234(optasm) bytes allocated: 91583520 Deviation T12234(optasm) bytes allocated: 14.6 % *** unexpected stat test failure for T12234(optasm) }}} These are a bit too high for me to just blindly update them without knowing why. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15668> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15670: FloatFnInverses seems to show some weird rounding/precision issues.
by GHC 23 Sep '18

23 Sep '18

#15670: FloatFnInverses seems to show some weird rounding/precision issues. ----------------------------------------+--------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- There seems to be a rounding issue with math functions on Windows. We likely need a crt update to fix this. Or maybe check the round mode if it's being set correctly. {{{ --- numeric/should_run/FloatFnInverses.run/FloatFnInverses.stdout.normalised 2018-09-23 17:26:01.581150200 +0100 +++ numeric/should_run/FloatFnInverses.run/FloatFnInverses.run.stdout.normalised 2018-09-23 17:26:01.583146400 +0100 @@ -8,8 +8,8 @@ [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0] [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0] [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0] -[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0] -[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0] +[Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity] +[7.788445287802241e33,7.788445287802241e33,7.788445287802241e33,7.788445287802241e33,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33] [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0] [0.0,0.0,0.0,0.0,0.0,0.0] [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15670> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0