March 2017 - ghc-tickets

[GHC] #12506: Compile time regression in GHC 8.
by GHC 07 Mar '18

07 Mar '18

#12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- This bug is entirely reproducible but unfortunately takes some setup. I don't have a minimal example. The regression is happening in FLTKHS (https://github.com/deech/fltkhs) the Haskell bindings to the FLTK(http://fltk.org) toolkit, and in particular to this GUI (https://github.com/deech/fltkhs/blob/master/images /tree-complex-windows.png). In GHC 7.8, it taks 5-9 seconds to compile and link in 7.10.3, that goes up to 12-15 seconds and finally in GHC 8 it shoots up to 45 seconds. While these numbers come from my i7, 16GB RAM Linux laptop, the compile time regression is proportionally reproducible across machines and operating systems. Here are the steps to reproduce it * Install FLTK Please follow the instructions here (https://github.com/deech/fltkhs #linux-and-bsd) but only the first set which about for installing FLTK 1.3. * Clone the repo with the offending application: `git clone https://github.com/deech/fltkhs-fluid-demos` * Build the application and reproduce the problem: - `cabal install fltkhs` - At the root of the repo do `cabal build fltkhs-fluid-tree` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12506> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34

[GHC] #12158: ghc: panic! (the 'impossible' happened) translateConPatVec: lookup
by GHC 05 Mar '18

05 Mar '18

#12158: ghc: panic! (the 'impossible' happened) translateConPatVec: lookup -------------------------------------+------------------------------------- Reporter: wozgonon | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- *Main> price Stock{name=name,ric=ric,price=price} = price ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-mingw32): translateConPatVec: lookup Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12158> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #13193: Integer (gmp) performance regression?
by GHC 05 Mar '18

05 Mar '18

#13193: Integer (gmp) performance regression? -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For a simple program that uses Integer, but actual data would fit in an Int, ghc-8.0.2 seems to have more runtime overhead than ghc-6.12.3 had: http://www.imn.htwk-leipzig.de/~waldmann/etc/mob/ I am not really sure what to make of it - an answer could be: "if you know that your Integer fits in an Int, then just use Int". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13193> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #8772: ghci should safe history more often
by GHC 05 Mar '18

05 Mar '18

#8772: ghci should safe history more often ----------------------------------------------+---------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- It is very annoying if `ghci` crashes (due to using a foreign library wrongly, for example), and then the history is lost. It should be simple to save each line to history before it is being executed. Maybe a good task for new contributors? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8772> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12935: Object code produced by GHC is non-deterministic
by GHC 05 Mar '18

05 Mar '18

#12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- This is a continuation of #4012, which made interface files deterministic. Now someone needs to make object code deterministic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12935> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #11984: Pattern match incompleteness / inaccessibility discrepancy
by GHC 02 Mar '18

02 Mar '18

#11984: Pattern match incompleteness / inaccessibility discrepancy -------------------------------------+------------------------------------- Reporter: goldfire | 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: -------------------------------------+------------------------------------- Consider this module: {{{ {-# LANGUAGE PolyKinds, TypeOperators, DataKinds, TypeFamilies, GADTs #-} module Bug where data family Sing (a :: k) data Schema = Sch [Bool] data instance Sing (x :: Schema) where SSch :: Sing x -> Sing ('Sch x) data instance Sing (x :: [k]) where SNil :: Sing '[] SCons :: Sing a -> Sing b -> Sing (a ': b) data G a where GCons :: G ('Sch (a ': b)) eval :: G s -> Sing s -> () eval GCons s = case s of -- SSch SNil -> undefined SSch (SCons _ _) -> undefined }}} Upon seeing this, GHC says {{{ Bug.hs:21:9: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: (SSch SNil) }}} So I uncomment the second-to-last line, inducing GHC to say {{{ Bug.hs:22:16: error: • Couldn't match type ‘a : b’ with ‘'[]’ Inaccessible code in a pattern with constructor: SNil :: forall k. Sing '[], in a case alternative • In the pattern: SNil In the pattern: SSch SNil In a case alternative: SSch SNil -> undefined }}} Thankfully, this pattern is much rarer than it once was, but it's a bit sad that it's still possible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11984> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12706: Collecting type info is slow
by GHC 02 Mar '18

02 Mar '18

#12706: Collecting type info is slow -------------------------------------+------------------------------------- Reporter: vshabanov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- With `:set +c` option in GHCi, I'm waiting for 10-15 seconds for {{{ Collecting type info for 34 module(s) ... }}} after both first load and subsequent reloads, even if only top-level module was modified. And GHCi uses about 1.5-2x more memory than it uses without `:set +c`. My app has about 30k lines of code. Is it expected behavior and some performance improvements are planned or it's a bug? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12706> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins
by GHC 02 Mar '18

02 Mar '18

#12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When building lambdabot-haskell-plugins, Lambdabot.Plugin.Haskell.Pl.Parser compiles without incident on the non- profiling run, but cripples the build machine on the profiling run. An excerpt of -v3 output is below to show the number of terms skyrocketing. *** Common sub-expression [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Common sub-expression = {terms: 39,049, types: 30,851, coercions: 990} !!! Common sub-expression [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 72.00 milliseconds, allocated 44.536 megabytes *** Float inwards [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Float inwards = {terms: 39,049, types: 30,851, coercions: 990} !!! Float inwards [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 68.00 milliseconds, allocated 60.337 megabytes *** Simplifier [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Simplifier iteration=1 = {terms: 977,045, types: 299,334, coercions: 1,058} Result size of Simplifier iteration=2 = {terms: 926,036, types: 263,306, coercions: 932} Result size of Simplifier = {terms: 922,724, types: 262,202, coercions: 932} !!! Simplifier [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 15480.00 milliseconds, allocated 9384.823 megabytes *** CoreTidy [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Tidy Core = {terms: 922,623, types: 261,789, coercions: 865} !!! CoreTidy [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 2060.00 milliseconds, allocated 613.585 megabytes writeBinIface: 95 Names writeBinIface: 259 dict entries *** CorePrep [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of CorePrep = {terms: 1,128,145, types: 347,063, coercions: 865} !!! CorePrep [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 3468.00 milliseconds, allocated 1718.453 megabytes *** Stg2Stg: *** CodeGen [Lambdabot.Plugin.Haskell.Pl.Parser]: -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12790> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #13075: Top-level bang pattern accepted
by GHC 27 Feb '18

27 Feb '18

#13075: Top-level bang pattern accepted -------------------------------------+------------------------------------- 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I compile/link {{{#!hs {-# LANGUAGE BangPatterns #-} module Main where !(Just x) = Nothing main = putStrLn "hi there!" }}} I get {{{ rae:09:50:49 ~/temp> ghc Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... ld: can't open output file for writing: Bug, errno=21 for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) `gcc' failed in phase `Linker'. (Exit code: 1) }}} This bogus code should be rejected more gracefully (and earlier). It actually also loads into GHCi, but shouldn't. Will fix while I'm in the area. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13075> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #11107: Can't use type wildcard infix
by GHC 26 Feb '18

26 Feb '18

#11107: Can't use type wildcard infix -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 fails: {{{ foo :: Int `_a` Bool foo = Right True }}} But moving `_a` to be prefix works. I observe the same behavior with an unnamed type wildcard. This was discovered while poking around in the renamer, not in real code! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11107> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1