December 2014 - ghc-tickets

[GHC] #9574: GHC Panic: No Skolem Info
by GHC 05 Sep '17

05 Sep '17

#9574: GHC Panic: No Skolem Info -------------------------------------+------------------------------------- Reporter: ian_mi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- GHC 7.8.3 and from git both panic with Couldn't match kind ‘o1’ with ‘(,) o o’ ‘o1’ is untouchable inside the constraints (Object (c :><: c) a) bound by a type expected by the context: Object (c :><: c) a => Tagged a (c (FMap (ProductF c) a) (FMap (Proj2 c c) a)) at Product.hs:35:9-15ghc: panic! (the 'impossible' happened) (GHC version 7.9.20140908 for x86_64-unknown-linux): No skolem info: o1_a6XS I have not yet attempted to reduce the problem at all. The offending code is the use of fmap here: {{{#!hs proj2 :: forall (c :: o -> o -> *). ProductCategory c => NatTr (c :><: c) c (ProductF c) (Proj2 c c) proj2 = NatTr t where NatTr t = fmap (CompF Proj2 IdentityF) e e :: NatTr (c :><: c) (c :><: c) (Comp ('KProxy :: KProxy o) (Diag c) (ProductF c)) (IdentityF (c :><: c)) e = counit }}} fmap is defined as {{{#!hs fmap :: forall f (a :: o1) (b :: o1). Functor f ('KProxy :: KProxy (o1 -> o2)) => f -> Domain f a b -> Codomain f (FMap f a :: o2) (FMap f b :: o2) fmap _ = proxy morphMap (Proxy :: Proxy f) }}} while CompF is defined by {{{#!hs data CompF f g (k :: KProxy (o3 -> o4, o1 -> o2)) where CompF :: (Functor f ('KProxy :: KProxy (o3 -> o4)), Functor g ('KProxy :: KProxy (o1 -> o2))) => f -> g -> CompF f g ('KProxy :: KProxy (o3 -> o4, o1 -> o2)) }}} This makes some sense because there is a functional dependency between the functor and the kind proxy. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9574> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8317: Optimize tagToEnum# at Core level
by GHC 29 Aug '17

29 Aug '17

#8317: Optimize tagToEnum# at Core level ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6135 | ------------------------------------+------------------------------------- Old comparison primops that returned Bool were implemented by inserting call to `tagToEnum#` in the code generator. This call to `tagToEnum#` was later optimized away by a special case in the code geenrator (see [[GhcFile(compiler/codeGen/StgCmmExpr.hs)]], Note [case on bool])). Now that we have new comparison primops (see #6135) we no longer insert `tagToEnum#` in the code generator - all uses of `tagToEnum#` come from explicit calls in a source program. But we still have that special case in the code generator to optimize away `tagToEnum#`. We should drop that special case in the code generator and handle scrutinizing of `tagToEnum#` at the Core level by: 1. removing call to `tagToEnum#` in the scrutinee 2. adding calls to `dataToTag#` in case branches 3. constant-folding inserted `dataToTag#` Here is an example. This Haskell code: {{{ if tagToEnum# (a ># b) then E1 else E2 }}} will be translated to this Core: {{{ case tagToEnum# (a ># b) of True -> E1 False -> E2 }}} and optimized like this: {{{ case a ># b of dataToTag# True -> E1 dataToTag# False -> E2 }}} ====> {{{ case a ># b of 1 -> E1 0 -> E2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8317> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9352: Allow `State# s` argument/result types in `ccall` FFI imports
by GHC 16 Aug '17

16 Aug '17

#9352: Allow `State# s` argument/result types in `ccall` FFI imports -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: #9218 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This ticket is to allowing code like {{{#!hs {-# LANGUAGE UnliftedFFITypes #-} {-# LANGUAGE MagicHash #-} module M where import GHC.Exts foreign import ccall unsafe "foo" c_foo :: Int# -> State# s -> State# s foreign import ccall unsafe "bar" c_foo :: Int# -> State# s -> (# State# s, Int# #) }}} See also discussion in #9218 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9352> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8472: Primitive string literals prevent optimization
by GHC 16 Aug '17

16 Aug '17

#8472: Primitive string literals prevent optimization ------------------------------+-------------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime performance bug (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Using an Addr# literal seems to result in less aggressive optimization. If I compile the attached program like this: {{{ ghc -O2 -fforce-recomp -ddump-simpl addr.hs }}} the code is optimized nicely. Everything are inlined into {{{t}}}, intermediate pairs are eliminated, etc. However, when I replace the Int# literals in the code with Addr# literals by defining the {{{ADDR}}} macro: {{{ ghc -O2 -fforce-recomp -ddump-simpl -DADDR addr.hs }}} GHC now creates 2 extra top-level bindings, each of which allocates a pair. I don't see why the presence of Addr# literals should prevent inlining, so I'm reporting a bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8472> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #9577: String literals are wasting space
by GHC 15 Aug '17

15 Aug '17

#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (NCG) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- For [https://phabricator.haskell.org/D199 D199] I looked into how string literals are compiled down by GHC. On 64-bit OS X, a simple string `"AAA"` turns into assembly: {{{ .const .align 3 .align 0 c38E_str: .byte 65 .byte 65 .byte 65 .byte 0 }}} (And also something that invokes `unpackCString#`, but that isn't relevant here.) (`MkCore.mkStringExprFS` -> `CmmUtils.mkByteStringCLit` -> `compiler/nativeGen/X86/Ppr.pprSectionHeader`.) Note how this: * Is 8 byte aligned. * Is a `.const` section. I can't find any reason why string literals would need to be 8-byte aligned on OS X. There might be a small benefit in performance to read data starting 8-byte aligned, but I doubt doing that for string literals would be a meaningful difference. Assembly from both clang and gcc does not align string literals. The trivial program: {{{#!hs main :: IO () main = return () }}} has almost 5kB of wasted space of padding between all strings the Prelude brings in, built with GHC HEAD. The fact that it is a `.const` section, instead of `.cstring` (https://developer.apple.com/library/mac/documentation/DeveloperTools/Refere…) means duplicate strings aren't shared by the assembler. GHC floats out string literals to the top-level and uses CSE to eliminate duplicates, but that only works in a single modules. Strings shared between different modules end up as duplicate strings in an executable. The same program as above also has ~4kB of wasted space due to duplicate Prelude strings (`"base"` occurs 16 times!). Compared to the total binary size (4MB after stripping), removing this redundant data wouldn't be a big improvement (0.2%), but I still think it can be a worthwile optimization. I think this can be solved quite easily by creating a new section header for literal strings, which is unaligned and of type `.cstring`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9577> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #8147: Exponential behavior in instance resolution on fixpoint-of-sum
by GHC 07 Aug '17

07 Aug '17

#8147: Exponential behavior in instance resolution on fixpoint-of-sum -------------------------+------------------------------------------------- Reporter: | Owner: jkoppel | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: performance, | Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Doing instance resolution on a fixpoint-of-sum type takes a very long time. This is possibly the same issue as issue #5642. These are the numbers I see for various n: {{{ 10 : 0.329s 20 : 0.479s 40 : 0.935s 80 : 2.821s 160 : 11.694s 320 : 1m30.39s 640: Ran for over 1 hour without terminating }}} This uses a couple of attached support files. Apologies for not being able to reduce further. {{{ -- Test.hs {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, UndecidableInstances, OverlappingInstances, TypeOperators, DeriveFunctor, TemplateHaskell #-} module Test where import Control.Monad import Lib import TH {- With n=3, produces data X1 e = X1 e deriving (Functor) data X2 e = X2 e deriving (Functor) data X3 e = X3 e deriving (Functor) type X = X1 :+: X2 :+: X3 -} $(let n = 320 in liftM concat $ sequence [liftM concat $ mapM mkDec $ map (('X':).show) [1..n] , makeSumType "X" (map (('X':).show) [1..n])]) data Y0 e = Y0 e deriving ( Functor ) type X' = Y0 :+: X class Lift f g where lift' :: f (Fix g) -> Fix g instance (Lift f g, Lift f' g) => Lift (f :+: f') g where lift' x = case x of L e -> lift' e R e -> lift' e instance (Functor f, f :<: g) => Lift f g where lift' = In . inj cata :: (Functor f) => (f a -> a) -> Fix f -> a cata f = f . fmap (cata f) . out lift :: Fix X -> Fix X' lift = cata lift' }}} Virtually all the time is spent in compiling lift. For example, with n=640, commenting out lift makes it compile in around 2 seconds. Interestingly, when I add the following code, compilation times only increase by 10-20%. In the original code where I encountered this issue, doing so doubles compilation time. {{{ instance Lift Y0 X where lift' = undefined lower :: Fix X' -> Fix X lower = cata lift' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9522: SPECIALISE pragmas for derived instances
by GHC 01 Aug '17

01 Aug '17

#9522: SPECIALISE pragmas for derived instances -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In package `ghc-prim`, in `GHC.Classes` we have {{{ instance (Eq a) => Eq [a] where {-# SPECIALISE instance Eq [[Char]] #-} {-# SPECIALISE instance Eq [Char] #-} {-# SPECIALISE instance Eq [Int] #-} [] == [] = True (x:xs) == (y:ys) = x == y && xs == ys _xs == _ys = False }}} The `SPECIALISE instance` pragmas instantiate the code for these commonly- used types. But for tuples we use `deriving`: {{{ deriving instance (Eq a, Eq b) => Eq (a, b) }}} and many more similar. There is no way to add a `SPECIALISE instance` pragma for a derived instance. This is bad, because they are heavily used. It should probably be possible to have a top-level {{{ {-# SPECIALISE instance Eq (Int, Bool) #-} }}} even in another module (as we can now do for functions. To do this right, we'd need to make the code for derived methods `INLINEALBE`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9522> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong
by GHC 01 Aug '17

01 Aug '17

#8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider the following modules: {{{ module A (List, ints) where data List a = Nil | Cons a (List a) infixr 4 `Cons` ints :: List Int ints = 1 `Cons` 2 `Cons` 3 `Cons` Nil }}} {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} module B where import A newtype Age = MkAge Int deriving C class C a where cList :: List a instance C Int where cList = ints }}} {{{ {-# LANGUAGE Safe #-} module C (ages) where import A import B ages :: List Age ages = cList }}} Module C compiles without a hiccup. But, it shouldn't: the coercion between `ages` and `ints` (performed by !GeneralizedNewtypeDeriving in module B) isn't Safe, as it breaks through `List`'s abstraction. (Note that the constructors of `List` are ''not'' exported from module A!) If module B includes `{-# LANGUAGE Safe #-}`, it duly doesn't compile, because of the stringent "constructors-must-be-in-scope" check done by the `Coercible` mechanism. The problem is that safety can be ''inferred'' without this check taking place. You may also want to read the commentary on #8745 for related discussion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8827> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 52

[GHC] #9790: Produce coercion rules for derived Functor instances
by GHC 01 Aug '17

01 Aug '17

#9790: Produce coercion rules for derived Functor instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: coercion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I don't ''think'' we do this yet, but I think we probably can. If we derive a `Functor` instance, we should, whenever possible and valid, produce some sort of `fmap coerce = coerce` rule for that type. This is done manually for lists in `GHC.Base`, but I imagine it probably applies (much) more generally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9790> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving?
by GHC 01 Aug '17

01 Aug '17

#8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Nathan Howell posts this code: {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} -- Uncomment to compile on GHC 7.8 -- {-# LANGUAGE ImpredicativeTypes #-} module Repro where import Control.Monad.Trans.Cont import Control.Monad.Trans.State.Lazy newtype AnyContT m a = AnyContT { unAnyContT :: forall r . ContT r m a } class MonadAnyCont b m where anyContToM :: (forall r . (a -> b r) -> b r) -> m a instance MonadAnyCont b (AnyContT m) where anyContToM _ = error "foo" data DecodeState = DecodeState newtype DecodeAST a = DecodeAST { unDecodeAST :: AnyContT (StateT DecodeState IO) a } deriving (MonadAnyCont IO) }}} Compiling on HEAD produces {{{ [1 of 1] Compiling Repro ( repro.hs, interpreted ) repro.hs:24:13: Cannot instantiate unification variable ‛b0’ with a type involving foralls: (forall r. (a1 -> IO r) -> IO r) -> DecodeAST a1 Perhaps you want ImpredicativeTypes In the expression: GHC.Prim.coerce (anyContToM :: (forall (r :: *). (a -> IO r) -> IO r) -> AnyContT (StateT DecodeState IO) a) :: forall (a :: *). (forall (r :: *). (a -> IO r) -> IO r) -> DecodeAST a In an equation for ‛anyContToM’: anyContToM = GHC.Prim.coerce (anyContToM :: (forall (r :: *). (a -> IO r) -> IO r) -> AnyContT (StateT DecodeState IO) a) :: forall (a :: *). (forall (r :: *). (a -> IO r) -> IO r) -> DecodeAST a Failed, modules loaded: none. }}} Two questions: 1. Should we require users to specify !ImpredicativeTypes here? Or, should the !GeneralizedNewtypeDeriving mechanism (which sometimes is impredicative) just assume the extension? 2. Can we improve the error message? I'd like to note that the original example really ''does'' require impredicativity -- the question is whether and how to bother the user with this technicality. Small program note: I've done a lot of stuff with !GeneralizedNewtypeDeriving lately but am on holiday until Jan. 6, so don't expect responses! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8631> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17