September 2017 - ghc-tickets

[GHC] #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm)
by GHC 07 Mar '18

07 Mar '18

#11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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: -------------------------------------+------------------------------------- {{{ $ ghc-head --info | grep Project [("Project name","The Glorious Glasgow Haskell Compilation System") ,("Project version","8.1.20151231") ,("Project Git commit id","8afeaad919dc67643b4eff14efafb48b59039b2b") }}} {{{ $ make slowtest TEST=dynamic-paper VERBOSE=2 TEST_HC=ghc-head ... =====> dynamic-paper(normal) 1 of 1 [0, 0, 0] =====> dynamic-paper(hpc) 1 of 1 [0, 0, 0] ... Compile failed (status 256) errors were: *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) *** <no location info>: warning: In a case alternative: (TypeRepX k_s7Ec :: *, a_s7Ed :: k_a5px, tr2_s7Ee :: TypeRep a_s7Ed) @ k_a5px is out of scope *** Offending Program *** ... <no location info>: error: Compilation had errors *** unexpected failure for dynamic-paper(hpc) =====> dynamic-paper(optasm) 1 of 1 [0, 1, 0] Compile failed (status 256) errors were: ghc: panic! (the 'impossible' happened) (GHC version 8.1.20151231 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone delta1 To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 203160 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for dynamic-paper(optasm) Unexpected results from: TEST="dynamic-paper" }}} This test was added in commit 52da6bdc17bb491d6d2f462b3680eb44b9be92e5: {{{ Author: Richard Eisenberg <eir(a)cis.upenn.edu> Date: Sat Dec 26 09:11:33 2015 -0500 Have mkCastTy look more closely for reflexivity. This may have performance implications. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11330> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[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] #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match
by GHC 06 Mar '18

06 Mar '18

#14105: ApplicativeDo causes GHC panic on irrefutable list pattern match -------------------------------------+------------------------------------- Reporter: BoteboTsebo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: ApplicativeDo | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- So this just happened: {{{#!hs {-# language ApplicativeDo #-} module Main where main :: IO () main = do [_] <- pure [] pure () }}} Compiling (under Stack) with `stack exec -- ghc --make src/Main.hs` yields {{{ [1 of 1] Compiling Main ( src/Main.hs, src/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): isStrictPattern Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This does not happen on GHC-8.0.2. It does not happen when `ApplicativeDo` is not activated. It also does not happen when the pattern match line is changed to {{{#!hs [] <- pure [] }}} For completeness, the compiler used by `stack` is that which comes with `nightly-2017-08-10`. I am on Linux x64 (Ubuntu). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14105> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[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] #14098: Incorrect pattern match warning on nested GADTs
by GHC 02 Mar '18

02 Mar '18

#14098: Incorrect pattern match warning on nested GADTs -------------------------------------+------------------------------------- Reporter: jmgrosen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language GADTs #-} data App f a where App :: f a -> App f (Maybe a) data Ty a where TBool :: Ty Bool TInt :: Ty Int data T f a where C :: T Ty (Maybe Bool) -- Warning f :: T f a -> App f a -> () f C (App TBool) = () -- No warning g :: T f a -> App f a -> () g C (App x) = case x of TBool -> () }}} When compiling, with `-Wincomplete-patterns`: {{{ Foo.hs:15:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘f’: Patterns not matched: C (App TInt) | 15 | f C (App TBool) = () | ^^^^^^^^^^^^^^^^^^^^ }}} I'm sorry for such a complicated example, but I wasn't able to reduce it any further than this. The gist of the problem is that this code gives a pattern matching non- exhaustiveness warning when matching a nested pattern, when pulling out a value then matching on it produces no warning (correctly). It also seems to have to do with using a type constructor (`Maybe`) within the constructor definition of `App`, as changing it to {{{#!hs data App f a where App :: f a -> App f a ... data T f a where C :: T Ty Bool }}} does not give a warning, even when `App` is modified further to force it to be a proper GADT. This might be a known limitation of the checker, but given that it works fine when the nesting is removed, I would think it would be more of a bug. Thanks to Iavor for helping me minimize the test case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14098> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[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