December 2017 - ghc-tickets

[GHC] #10535: Float out causes major space leak
by GHC 08 Dec '17

08 Dec '17

#10535: Float out causes major space leak -------------------------------------+------------------------------------- Reporter: AlexET | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- This issue originally was on haskell-cafe https://mail.haskell.org/pipermail/haskell-cafe/2015-June/120113.html The following code has a space leak {{{ #!hs numbers = [1..200] replicateM' :: Monad m => Int -> m a -> m [a] replicateM' 0 xs = return [] replicateM' n xs = do a <- xs b <- replicateM' (n-1) xs return (a:b) test :: [[Int]] test = replicateM' 4 numbers main = print test }}} The recursive call in replicateM' gets floated out. This then causes a very large (200^3 elements) list to be kept in memory instead of being lazily produced and consumed each time. A similar thing happens to the replicateM in Control.Monad but it is harder to spot as a lot of specialisation and fusion goes on before the float-out happens This is similar to #7367 but in this case we have a huge space-leak instead of just adding allocations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10535> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14562: IntRep vs WordRep
by GHC 07 Dec '17

07 Dec '17

#14562: IntRep vs WordRep -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- Why do `Int#` and `Word#` have different runtime representations? By this I mean that: {{{#!hs Int# :: TYPE 'IntRep Word# :: TYPE 'WordRep }}} To my understanding, they are always the same size and always live in the same set of registers. The docs for unsafeCoerce# state that it can be used for: > Casting an unboxed type to another unboxed type of the same size (but not coercions between floating-point and integral types) The implies that a cast between `Int#` and `Word#` is acceptable. But if you're able to unsafeCoerce# between two types, shouldn't they be defined as having the same representation? What I'm suggesting is that it may be better to collapse `IntRep` and `WordRep` into a single representation (probably named `WordRep`). We would then get slightly more reusable code in some cases: {{{#!hs data WordList (x :: TYPE 'WordRep) = WordListCons x (WordList x) | WordListNil ints :: WordList Int# ints = WordListCons 5# (WordListCons 8# WordListNil) words :: WordList Word# words = WordListCons 4## (WordListCons 12## WordListNil) mapWordList :: forall (x :: TYPE 'WordRep). (x -> x) -> WordList x -> WordList x mapWordList _ WordListNil = WordListNil mapWordList f (WordListCons x xs) = WordListCons (f x) xs biggerInts :: WordList Int# biggerInts = mapWordList (\x -> x +# 3) ints biggerWords :: WordList Int# biggerWords = mapWordList (\x -> plusWord# x 3) ints }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14562> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #481: Recompilation check fails for TH
by GHC 07 Dec '17

07 Dec '17

#481: Recompilation check fails for TH -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Template Haskell | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: TH_recompile Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by saurabhnanda): > We already do that stability check. My earlier comment was more about whether anyone has studied the perf- impact of the existing stability check. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/481#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14560: Typo in example on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms
by GHC 06 Dec '17

06 Dec '17

#14560: Typo in example on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Keywords: type error | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In section Associated pattern synonyms on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms is written class ListLike l where pattern Nil :: l a pattern Cons :: a -> l a -> a isNil :: l a -> Bool isNil Nil = True isNil (Cons _ _) = False yet should Cons not have signature pattern Cons :: a -> l a -> l a append :: l a -> l a -> l a -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14560> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #481: Recompilation check fails for TH
by GHC 06 Dec '17

06 Dec '17

#481: Recompilation check fails for TH -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Template Haskell | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: TH_recompile Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): We already do that stability check. But recompilation of TH could be improved if we had a better idea of what the TH code actually depended on - when it's arbitrary I/O, we have to be necessarily conservative and assume that anything could change. There's some design to do here to figure out what a better solution would look like. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/481#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14559: When overlapping instances lead to a compile error, show import chains for the instances
by GHC 06 Dec '17

06 Dec '17

#14559: When overlapping instances lead to a compile error, show import chains for the instances -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | 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: -------------------------------------+------------------------------------- Here's an example from work: {{{ • Overlapping instances for ToJSON BackupPhrase arising from a use of 'aesonRoundtripProp' Matching instances: instance ToJSON BackupPhrase -- Defined in 'Cardano.Wallet.Orphans.Aeson' instance ToJSON BackupPhrase -- Defined in 'Pos.Wallet.Aeson.ClientTypes' }}} Currently resolving such issues requires looking carefully at all imports and trying to guess which ones bring the instance into scope. It'd be quite helpful if the error was explicit about the import chain: {{{ • Overlapping instances for ToJSON BackupPhrase arising from a use of 'aesonRoundtripProp' Matching instances: instance ToJSON BackupPhrase -- Defined in 'Cardano.Wallet.Orphans.Aeson', -- imported by 'Cardano.Wallet.Orphans' instance ToJSON BackupPhrase -- Defined in 'Pos.Wallet.Aeson.ClientTypes', -- imported by 'Pos.Wallet.Web.Mode', -- and then by 'Cardano.Wallet.API.V1.Migration' }}} Thoughts? I'm worried about two things here: 1. Might these chains get too long? 2. Is it sufficiently obvious that “imported by `A` and then by `B`” means that you have imported `B` and `B` imported `A`, and not vice-versa? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14559> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14557: NoFib : fasta benchmark produces unexpected output on slow/fast modes.
by GHC 05 Dec '17

05 Dec '17

#14557: NoFib : fasta benchmark produces unexpected output on slow/fast modes. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: NoFib | Version: benchmark suite | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I aborted after hitting this one so maybe the issue exists for other benchmarks as well. Fails with HEAD/stage2 and ghc-8.2.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14557> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14524: Use sortOn instead of sortWith
by GHC 04 Dec '17

04 Dec '17

#14524: Use sortOn instead of sortWith -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `sortWith`provides the same functionality as `sortOn` from `Data.List`. As sortOn is already part of Prelude it makes sense for the GHC source to use it as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14524> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14548: Lexically scoped kind variables
by GHC 03 Dec '17

03 Dec '17

#14548: Lexically scoped kind variables -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- Consider this, with `ScopedTypeVariables`: {{{ f :: forall a. Char -> Proxy (a::k) -> Int f = <body> }}} Clearly `a` scopes over `<body>`. But did you know that `k` does too? I think we'd ''expect'' `k` to scope if we wrote {{{ f :: forall (a :: K). Char -> Proxy (a::k) -> Int }}} with `k` appearing in the kind of an explicitly-forall'd binder. For long time we could not have an explicit forall for a kind variable (although we can now), so this was the ''only'' way to bring `k` into scope. But it seems altogether less desirable that an occurrence of `k` buried deep in the type should scope over `f`'s body. That's why we don't make implicitly-bound type variables scope over the body: {{{ f :: Char -> Proxy (a::k) -> Int }}} Here `a` does ''not'' scope over `<body>`. I doubt anyone would notice if we changed this behaviour, like this. * A type variable from the signature scopes over the body if * It is explicitly forall'd, or * It appears in a kind annotation of an explicitly-forall'd type variable My reason for raising this is that it's solve #14498, (by making `kk` not scope) in a uniform way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14548> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #1290: ghc runs preprocessor too much
by GHC 03 Dec '17

03 Dec '17

#1290: ghc runs preprocessor too much -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.7 Resolution: | Keywords: cpp Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: 14553 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * keywords: => cpp -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1290#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0