February 2018 - ghc-tickets

[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] #14701: Investigate the performance impact of code alignment
by GHC 03 Mar '18

03 Mar '18

#14701: Investigate the performance impact of code alignment -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (CodeGen) | 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: -------------------------------------+------------------------------------- Maybe ghc's performance also varies due to reasons like that: https://dendibakh.github.io/blog/2018/01/18/Code_alignment_issues The gist of the article is that tight loops can have significantly different performance depending on whether the location of the assembly instructions themselves cross a cache line. I would not have expected this to make double-digit percentage differences. From `#ghc`: {{{ bgamari: nh2[m], there are nofib tests where this is very likely the cause of a good portion of the variant angerman: nh2[m]: that linked LLVM talk from 2016 makes me not want to have to deal with that... AndreasK: nh2[m]: It's a real issue. But atm I think ghc at least in the native codegen make no real attempt to optimize for this thoughtpolice: GHC does not carry knowledge of alignment or anything, no. I’m not sure how difficult this is to suss out, but at least making sure every branch target does not cross a cache line is probably a good start thoughtpolice: Well, far jump, e.g. a call to a function. not sure how TNTC fits into this story, tbqh }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14701> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14796: Pretty-printer bug
by GHC 03 Mar '18

03 Mar '18

#14796: Pretty-printer bug -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- From Ryan's [https://ryanglscott.github.io/2018/02/11/how-to-derive- generic-for-some-gadts/ How to derive Generic for (some) GADTs using QuantifiedConstraints]: {{{#!hs data ECC ctx f a where ECC :: ctx => f a -> ECC ctx f a }}} When instantiating types using `-XTypeApplications` something weird happens {{{ $ ~/code/qc-ghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help Prelude> :set -XGADTs -XConstraintKinds -XTypeApplications Prelude> data ECC ctx f a where ECC :: ctx => f a -> ECC ctx f a Prelude> :t ECC @[] @() @() ECC @[] @() @() :: [()] -> ECC () :: Constraint [] () }}} Doesn't seem to happen in other cases: {{{ Prelude> :t ECC @[] @() @((), ()) ECC @[] @() @((), ()) :: [()] -> ECC (() :: Constraint, () :: Constraint) [] () Prelude> :t ECC @[] @() @(Eq Int) ECC @[] @() @(Eq Int) :: [()] -> ECC (Eq Int) [] () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14796> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14767: Move Data.Functor.Contravariant into base
by GHC 03 Mar '18

03 Mar '18

#14767: Move Data.Functor.Contravariant into base -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: base | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I propose that `Data.Functor.Contravariant` be moved to `base`. This has been discussed on the mailing list in 2016 and 2017: - https://mail.haskell.org/pipermail/libraries/2016-December/027480.html - https://mail.haskell.org/pipermail/libraries/2017-September/028190.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14767> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14849: Add Applicative, Semigroup and Monoid instances in GHC.Generics
by GHC 02 Mar '18

02 Mar '18

#14849: Add Applicative, Semigroup and Monoid instances in GHC.Generics -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 libraries/base | 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: -------------------------------------+------------------------------------- See https://mail.haskell.org/pipermail/libraries/2018-February/028562.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14849> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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] #14544: doCorePass has at least one missing case
by GHC 02 Mar '18

02 Mar '18

#14544: doCorePass has at least one missing case -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is a catch all at the end of `doCorePass` which hides the fact that `doCorePass` should be total. In particular `doCorePass` is not implemented for `CoreOccurAnal` and so either `CoreOccurAnal` should be removed from `CoreToDo` or implemented properly in `doCorePass`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14544> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4