December 2018 - ghc-tickets

Re: [GHC] #2289: Needless reboxing of values when returning from a tight loop
by GHC 19 Dec '18

19 Dec '18

#2289: Needless reboxing of values when returning from a tight loop -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: boxing, | loops, performance, CPRAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #2387,#1600 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: boxing, loops, performance => boxing, loops, performance, CPRAnalysis -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2289#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8598: IO hack in demand analyzer gets in the way of CPR
by GHC 19 Dec '18

19 Dec '18

#8598: IO hack in demand analyzer gets in the way of CPR ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- After a lot of staring at code and comparing unexpected nofib results I found the following: The IO hack in the demand analyzer (see `dmdAnalAlt` in `StrAnal.lhs` and #1592 for a good discussion) prevents CPR in any function that uses a C call. This is a small example, reduced from the `scaleFloat` method for doubles: {{{ module Float(fun) where import GHC.Float (Double(..)) import GHC.Integer (decodeDoubleInteger, encodeDoubleInteger) fun :: Double -> Double fun x | isFix = x | otherwise = case x of (D# x#) -> case decodeDoubleInteger x# of (# i, j #) -> D# (encodeDoubleInteger i j) where isFix = isDoubleFinite x == 0 foreign import ccall unsafe "isDoubleFinite" isDoubleFinite :: Double -> Int }}} Here, `fun` does current not get the CPR property, and the work gets type `GHC.Prim.Double# -> GHC.Types.Double`. Why? Because in core, there will be a {{{ case {__pkg_ccall main isDoubleFinite GHC.Prim.Double# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Prim.Int# #)}_dQD ds_dQA GHC.Prim.realWorld# of _ [Occ=Dead, Dmd=<L,A>] { (# ds_dQC [Dmd=<L,A>, OS=OneShot], ds_dQB [Dmd=<S,1*U>] #) -> ... }}} where the case body has `DmdType m {dQz-><L,1*U(U)> dQA-><L,U>}`, but `dmdAnalAlt` detects that this is evaluating a possibly exiting function and throws aways the information using `alt_ty `lubDmdType` topDmdType`. Would it be ok to `lub` only the demand on the free variables, but keep the CPR information? In nofib (if I managed to compare the right results) this does nothing for almost all benchmarks, `-9.2%` of allocations for `mandel` and `+4.9%` for reverse-complement (but these numbers are not obtained very cleanly, and all is happening on top of the better-ho-cardinality branch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8598> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 19 Dec '18

19 Dec '18

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: CPRAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Phab:D4244 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CPRAnalysis -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:84> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10905: Incorrect number of parameters in "role" errors
by GHC 19 Dec '18

19 Dec '18

#10905: Incorrect number of parameters in "role" errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: roles | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The following code produces the error: {{{ import Data.Coerce import Data.Functor.Trans.Tagged toTT :: Tagged t [a] -> TaggedT t [] a toTT = coerce }}} {{{ Couldn't match representation of type ‘[a]’ with that of ‘Data.Functor.Identity.Identity [a]’ arising from trying to show that the representations of ‘Tagged t [a]’ and ‘TaggedT t [] a’ are the same Relevant role signatures: type role [] representational type role Data.Functor.Identity.Identity representational type role TaggedT nominal nominal phantom representational nominal The data constructor ‘Data.Functor.Identity.Identity’ of newtype ‘Data.Functor.Identity.Identity’ is not in scope Relevant bindings include toTT :: Tagged t [a] -> TaggedT t [] a (bound at Main.hs:9:1) In the expression: coerce In an equation for ‘toTT’: toTT = coerce }}} First, kudos for correctly identifying the problem: I failed to import the `Identity` constructor. However, it seems that the report for the roles of the `TaggedT` type has too many parameters. It is defined in tagged-transformer [https://hackage.haskell.org/package/tagged-transformer-0.8/docs/Data- Functor-Trans-Tagged.html] as `newtype TaggedT s m b = TagT { untagT :: m b }`, but is listed with 5 roles. I did try to move the definition of `TaggedT/Tagged` into my module so I didn't have to import the library, but when I did the error didn't show up: TaggedT was listed with the expected roles `phantom representational nominal`. As a user, it wasn't clear to me why there are 5 roles listed for a type with 3 parameters, and I didn't know which roles I should be looking at to help me debug the `coerce` error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10905> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #16071: GHC is stuck (runs indefinitely) compiling a module
by GHC 19 Dec '18

19 Dec '18

#16071: GHC is stuck (runs indefinitely) compiling a module -------------------------------------+------------------------------------- Reporter: dirtypaw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling [https://github.com/agda/agda/commit/e68360b16af7865519bef77c21c66ff88139ea7e Agda] with ghc-8.6.3 using stack, ghc is stuck at [https://github.com/agda/agda/blob/master/src/full/Agda/Syntax/Internal.hs this module] (runs for 20+ min with no progress). It looks like a regression in ghc-8.6.3 on Windows as Agda is successfully built with ghc-8.6.2 on the same machine, and Agda build with ghc-8.6.3 is generally supported (see [https://github.com/agda/agda/issues/3442 this issue]). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16071> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16000: Don't suggest Rank2Types and RankNTypes, only the latter
by GHC 19 Dec '18

19 Dec '18

#16000: Don't suggest Rank2Types and RankNTypes, only the latter -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 (Parser) | 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: -------------------------------------+------------------------------------- Currently (as of GHC 8.6.2), error messages that suggest RankNTypes also suggest Rank2Types, but Rank2Types are deprecated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16000> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8959: GHCi should honour UnicodeSyntax
by GHC 19 Dec '18

19 Dec '18

#8959: GHCi should honour UnicodeSyntax -------------------------------------------+------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- When we load a module into GHCi with -XUnicodeSyntax, GHCi should default to printing information with the relevant unicode symbols. {{{ *Communication> let a ∷ Int; a = 7 *Communication> :t a a :: Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8959> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #16050: Instance resolution error message unclear, because of missing kind information
by GHC 19 Dec '18

19 Dec '18

#16050: Instance resolution error message unclear, because of missing kind information -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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 the following modules: {{{#!hs module A where (.) :: forall (a :: TYPE 'UnliftedRep) (b :: TYPE 'UnliftedRep) (c :: TYPE 'UnliftedRep). (b -> c) -> (a -> b) -> (a -> c) (.) f g = \x -> f (g x) data UList (a :: TYPE 'UnliftedRep) where UNil :: UList a UCons :: a -> UList a -> UList a mapFB :: forall (a :: TYPE 'UnliftedRep) (elt :: TYPE 'UnliftedRep) (lst :: Type). (elt -> lst -> lst) -> (a -> elt) -> a -> lst -> lst mapFB c f = \x ys -> c (f x) ys {-# RULES "mapFB" forall c f g. mapFB (mapFB c f) g = mapFB c (f . g) #-} }}} {{{#!hs module B where import Control.Category ((.)) data UList (a :: TYPE 'UnliftedRep) where UNil :: UList a UCons :: a -> UList a -> UList a mapFB :: forall (a :: TYPE 'UnliftedRep) (elt :: TYPE 'UnliftedRep) (lst :: Type). (elt -> lst -> lst) -> (a -> elt) -> a -> lst -> lst mapFB c f = \x ys -> c (f x) ys {-# RULES "mapFB" forall c f g. mapFB (mapFB c f) g = mapFB c (f . g) #-} }}} Module 'A' works fine. Module 'B', fails with the following error: {{{#!hs • No instance for (Category (->)) arising from a use of ‘.’ • In the second argument of ‘mapFB’, namely ‘(f . g)’ In the expression: mapFB c (f . g) When checking the transformation rule "mapFB" | line| "mapFB" forall c f g. mapFB (mapFB c f) g = mapFB c (f . g) | ^^^ }}} I expected this failure because of the kind mismatch; the category instance for `(->)` obviously requires that it be kinded `Type -> Type -> Type`. However, it confused someone I am teaching, who said to me that they didn't understand the error, since they expected it to work as `(->)` does indeed have a Category instance. (They are very unfamiliar with Levity-Polymorphism). My question is this: Would it be preferable to include such kind information in the error message? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16050> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #16068: Unsaturated type synonyms as arguments work in 8.6.3 but not HEAD
by GHC 19 Dec '18

19 Dec '18

#16068: Unsaturated type synonyms as arguments work in 8.6.3 but not HEAD -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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: -------------------------------------+------------------------------------- Input, derived from code seen in the wild in hpack 0.31.1: {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE FlexibleContexts #-} module Main where type WithCommonOptions cSources cxxSources jsSources a = a data Traverse m cSources cSources_ cxxSources cxxSources_ jsSources jsSources_ = Traverse { traverseCSources :: cSources -> m cSources_ , traverseCxxSources :: cxxSources -> m cxxSources_ , traverseJsSources :: jsSources -> m jsSources_ } type Traversal_ t = forall m cSources cSources_ cxxSources cxxSources_ jsSources jsSources_ a. Monad m => Traverse m cSources cSources_ cxxSources cxxSources_ jsSources jsSources_ -> t cSources cxxSources jsSources a -> m (t cSources_ cxxSources_ jsSources_ a) traverseWithCommonOptions :: Traversal_ WithCommonOptions traverseWithCommonOptions = undefined main = return () }}} Using a GHC compiled from revision 074eae255793de6a94e8172015e7022c80a5cd15, I get this error: {{{ Main.hs:19:30: error: • The type synonym ‘WithCommonOptions’ should have 4 arguments, but has been given none • In the type signature: traverseWithCommonOptions :: Traversal_ WithCommonOptions | 19 | traverseWithCommonOptions :: Traversal_ WithCommonOptions | }}} GHC 8.6.3 accepts the module without complaint. I'm actually surprised that the previous code worked and I wouldn't complain if this is closed as working as intended. However, there's no mention of this change in the migration guide for 8.8 yet, so I'm not certain it's intentional. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16068> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15503: interpreter: sequence_ (replicate 100000000 (return ())) gobbles up memory
by GHC 19 Dec '18

19 Dec '18

#15503: interpreter: sequence_ (replicate 100000000 (return ())) gobbles up memory -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I consider this to be more of a curiosity than a bug, but it might still be worth investigating. The following line, {{{#!hs sequence_ (replicate 100000000 (return ())) }}} causes `ghci` to grow quite big (here it's 6GB on 64 bit Linux; it's roughly proportional to the `100000000` number). This used to be better in ancient times--before version 8.0.1, ghci ran this code in what looks like constant memory. (This came up indirectly on #haskell; somebody had adapted Hutton's game of life program, http://www.cs.nott.ac.uk/~gmh/life.lhs which uses busy waiting for a delay.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15503> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17