- ghc-tickets - Haskell.org

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 06 Nov '17

06 Nov '17

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): Replying to [comment:15 bgamari]: > Well, I think simonpj's question was really "why is the same simplification not also being performed when we inline the unfolding?" Indeed this is a good question and will need some investigation. One explanation could be that `newTyConEtadRhs` is inlined at the callsite of `newTyConInstRhs` because the constructor of `tycon_a9Sq` is known; and after that substitution the logic in comment:9 no longer applies. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14424: lcm :: Word -> Word -> Word is not specialised
by GHC 06 Nov '17

06 Nov '17

#14424: lcm :: Word -> Word -> Word is not specialised -------------------------------------+------------------------------------- Reporter: Bodigrim | 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: -------------------------------------+------------------------------------- `GHC.Real` defines `gcd` with two specialised versions `gcdInt'` and `gcdWord'` and rules {{{ {-# RULES "gcd/Int->Int->Int" gcd = gcdInt' "gcd/Word->Word->Word" gcd = gcdWord' #-} }}} It also defines `lcm x y = abs ((x `quot` (gcd x y)) * y)`, but specialises it only for `Int`: {{{ {-# SPECIALISE lcm :: Int -> Int -> Int #-} }}} So `lcm :: Int -> Int -> Int` will be compiled to a nice and fast `gcdInt'`, but `lcm :: Word -> Word -> Word` will not benefit from the existence of `gcdWord'`. This leads to a huge performance gap, about 8x. Here is a test program: {{{ module Main where import Data.Time.Clock main :: IO () main = do t0 <- getCurrentTime print $ maximum $ [ lcm x y | x <- [1..1000 :: Int], y <- [1..1000 :: Int] ] t1 <- getCurrentTime putStrLn "lcm :: Int -> Int -> Int" print $ diffUTCTime t1 t0 t0 <- getCurrentTime print $ maximum $ [ lcm x y | x <- [1..1000 :: Word], y <- [1..1000 :: Word] ] t1 <- getCurrentTime putStrLn "lcm :: Word -> Word -> Word" print $ diffUTCTime t1 t0 t0 <- getCurrentTime print $ maximum $ [ lcmWord x y | x <- [1..1000 :: Word], y <- [1..1000 :: Word] ] t1 <- getCurrentTime putStrLn "lcmWord :: Word -> Word -> Word" print $ diffUTCTime t1 t0 -- Similar to GHC.Real.lcm, but specialized for Word lcmWord :: Word -> Word -> Word lcmWord _ 0 = 0 lcmWord 0 _ = 0 lcmWord x y = abs ((x `quot` (gcd x y)) * y) }}} On my PC the output is: {{{ 999000 lcm :: Int -> Int -> Int 0.086963s 999000 lcm :: Word -> Word -> Word 0.591168s 999000 lcmWord :: Word -> Word -> Word 0.077644s }}} My proposal is to add a SPECIALIZE pragma to `GHC.Real`: {{{ {-# SPECIALISE lcm :: Word -> Word -> Word #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14424> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 06 Nov '17

06 Nov '17

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > At the risk of stating the obvious, because the tick is around a `Case`, not a `Var`. Well, I think simonpj's question was really "why is the same simplification not also being performed when we inline the unfolding?" Indeed this is a good question and will need some investigation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14429: Remove constraint types from HsExtension, post TTG
by GHC 06 Nov '17

06 Nov '17

#14429: Remove constraint types from HsExtension, post TTG -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | 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: -------------------------------------+------------------------------------- Once Trees that Grow is landed on the hsSyn AST, remove the constraint types from `HsExtension.hs` Hopefully `DataId`, `HasSourceText`, `OutputableX` etc can all go. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14428: Rework HsValBindsLR
by GHC 06 Nov '17

06 Nov '17

#14428: Rework HsValBindsLR -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | 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: -------------------------------------+------------------------------------- Once Trees that Grow has been applied to the hsSyn AST, rework `HsValBindsLR` to simplify it. From a comment on https://phabricator.haskell.org/D4147 > Nothing here gives any clue that this is intended for the output of the renamer. And typechecker I think. > Plus I wonder if we'd be better served by {{{#!hs data HsValBindsLR idL idR = ValBinds [(RecFlag, LHsBindsLR idL idR)] [LSig GhcRn] }}} > Then the parser can generate a giant singleton Rec and the renamer can sort it out. Less fuss. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14428> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14426: Inferred type not principle/most general?
by GHC 06 Nov '17

06 Nov '17

#14426: Inferred type not principle/most general? -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- The type inferred for `(#)` is `H a a -> H a a -> H a a` (from [https://arxiv.org/pdf/1309.5135.pdf Coroutining Folds with Hyperfunctions]) {{{#!hs newtype H a b = Fn { invoke :: H b a -> b } -- ( # ) :: H a a -> H a a -> H a a f # g = Fn (\k -> invoke f (g # k)) }}} but a more general type is actually {{{#!hs ( # ) :: H b c -> H a b -> H a c f # g = Fn (\k -> invoke f (g # k)) }}} Is this expected or a blind spot in type inference ---- Same thing in ''ghci'' {{{ $ ghci -ignore-dot-ghci GHCi, version 8.3.20170920: http://www.haskell.org/ghc/ :? for help Prelude> :set prompt "> " > > newtype H a b = Fn { invoke :: H b a -> b } > > f # g = Fn (\k -> invoke f (g # k)) > :t ( # ) ( # ) :: H a a -> H a a -> H a a > > let ( # ) :: H b c -> H a b -> H a c; f # g = Fn (\k -> invoke f (g # k)) > :t ( # ) ( # ) :: H b c -> H a b -> H a c }}} Interestingly writing it in terms of `fix` does not type check with the more general type {{{ > import Data.Function > :t fix $ \self -> \f g -> Fn (\k -> invoke f (self g k)) fix $ \self -> \f g -> Fn (\k -> invoke f (self g k)) :: H a a -> H a a -> H a a > :t (fix $ \self -> \f g -> Fn (\k -> invoke f (self g k))) :: H b c -> H a b -> H a c <interactive>:1:2: error: • Couldn't match type ‘b1’ with ‘a1’ ‘b1’ is a rigid type variable bound by an expression type signature: forall b1 c1 a1. H b1 c1 -> H a1 b1 -> H a1 c1 at <interactive>:1:60-82 ‘a1’ is a rigid type variable bound by an expression type signature: forall b1 c1 a1. H b1 c1 -> H a1 b1 -> H a1 c1 at <interactive>:1:60-82 Expected type: H b1 c1 -> H a1 b1 -> H a1 c1 Actual type: H a1 a1 -> H a1 a1 -> H a1 a1 • In the expression: (fix $ \ self -> \ f g -> Fn (\ k -> ...)) :: H b c -> H a b -> H a c }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14426> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13824: ghc 8.2 does not build for me on ppc64le
by GHC 06 Nov '17

06 Nov '17

#13824: ghc 8.2 does not build for me on ppc64le ---------------------------------+---------------------------------------- Reporter: msuchanek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+---------------------------------------- [ 5732s] ghc-stage1: panic! (the 'impossible' happened) [ 5732s] (GHC version 8.2.0.20170613 for powerpc64le-unknown-linux): [ 5732s] dwarfReturnRegNo: Unsupported platform! [ 5732s] CallStack (from HasCallStack): [ 5732s] error, called at compiler/nativeGen/Dwarf/Constants.hs:225:19 in ghc:Dwarf.Constants [ 5732s] [ 5732s] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13824> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14422: {-# complete #-} should be able to be at least partially type directed
by GHC 06 Nov '17

06 Nov '17

#14422: {-# complete #-} should be able to be at least partially type directed -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 8779 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The fact that `{-# complete #-}` pragma that was added in#8779 is tied to the set of patterns only and not the types involved can make it rather awkward or impossible to use in practice. Say I have a bunch of types that happen to share a common `(:<)` and `Empty` pattern, for views. I'd like to be able to say that for one particular type `{-# complete (:<), Empty #-}` holds, but since both aren't defined in the same module and neither one mentions my type, I'm stuck in the same `-Wno-incomplete-patterns` mess I was in before. I cant move the pragma to the individual view patterns because in general they aren't known to be a complete pattern set. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14422> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14423: {-# complete #-} should be able to handle | like {-# minimal #-}
by GHC 06 Nov '17

06 Nov '17

#14423: {-# complete #-} should be able to handle | like {-# minimal #-} -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 8779 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It'd be really convenient to be able to specify these like we can with `minimal` pragmas, mixing ands and ors. I wind up with a combinatorial explosion of such annotations for the cases where it works when I have large numbers of patterns. I have at least one use case where something that would be a trivial pattern to express with one (complicated) expression involving `|` becomes 64 lines of complete pragmas, and every time I extend it this count doubles. Consider what happens if you add a mix of actual and smart views of a data type: {{{#!hs {-# language ViewPatterns, PatternSynonyms, GeneralizedNewtypeDeriving #-} newtype Delta = Delta Int deriving (Eq,Num) instance Monoid Delta where mempty = 0 mappend = (+) data Exp = Var !Int | AP !Delta !Exp !Exp | LAM !Delta !Exp rel 0 xs = xs rel d (AP d' l r) = AP (d + d') l r rel d (LAM d' b) = LAM (d + d') b rel _ (Var n) = Var n pattern Ap a b <- AP d (rel d -> a) (rel d -> b) where Ap a b = AP 0 a b pattern Lam b <- LAM d (rel d -> b) where Lam b = LAM 0 b {-# complete Var, AP, Lam #-} {-# complete Var, Ap, LAM #-} {-# complete Var, AP, LAM #-} }}} Every data constructor I add with a smart view adds to the powerset of complete pragmas I should supply. On the other hand with `|` patterns: {{{#!hs {-# complete Var, (Ap | AP), (Lam | LAM) #-} }}} extends linearly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14423> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #1460: Problem with Monoid instance of Data.Map
by GHC 06 Nov '17

06 Nov '17

#1460: Problem with Monoid instance of Data.Map -------------------------------------+------------------------------------- Reporter: ahey@… | Owner: (none) Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Resolution: fixed | Keywords: Data.Map | Monoid Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by txnull): I find both instances useful. Maybe there should not be a instance at all and everybody has to create one as needed or create both using newtypes? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1460#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0