September 2016 - ghc-tickets

[GHC] #10838: hsig files don't have good enough error checking for wired-in types
by GHC 05 Jan '17

05 Jan '17

#10838: hsig files don't have good enough error checking for wired-in types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- If I have the signature: {{{ {-# LANGUAGE NoImplicitPrelude #-} module MyPrelude where data Int a }}} And I compile it with `ghc MyPrelude.hsig -sig-of "MyPrelude is base:Prelude"` this won't actually give an error, despite `Int` having the wrong kind. The bug seems to be because `Int` is wired in and this case is not handled. Filing this so I don't forget to fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10838> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11564: Possible overzealous unfolding
by GHC 04 Jan '17

04 Jan '17

#11564: Possible overzealous unfolding -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------- I was investigating why (>>=) in the Haxl monad is being inlined more than I would expect, and I ran into something I don't fully understand, and looks dubious. Start from this standalone example: {{{ {-# LANGUAGE ScopedTypeVariables, ExistentialQuantification #-} module Haxl where import Data.IORef import Control.Exception newtype GenHaxl u a = GenHaxl { unHaxl :: Int -> IORef () -> IO (Result u a) } data Result u a = Done a | Throw SomeException | Blocked (Cont u a) data Cont u a = forall b. Cont u b :>>= (b -> GenHaxl u a) | forall b. (b -> a) :<$> (Cont u b) instance Monad (GenHaxl u) where return a = GenHaxl $ \_env _ref -> return (Done a) GenHaxl m >>= k = GenHaxl $ \env ref -> do e <- m env ref case e of Done a -> unHaxl (k a) env ref Throw e -> return (Throw e) Blocked cont -> return (Blocked (cont :>>= k)) instance Functor (GenHaxl u) instance Applicative (GenHaxl u) }}} (it could be simplified further, but I've intentionally used the exact definition of `>>=` that is used in Haxl to be sure I'm not investigating the wrong thing) Compile like this: {{{ ghc -O -c Haxl.hs }}} and look at the .hi file: {{{ ghc --show-iface Haxl.hi }}} see this: {{{ ea159c3b107c307a4e76cd310efcc8bc $fMonadGenHaxl2 :: GenHaxl u a -> (a -> GenHaxl u b) -> Int -> IORef () -> State# RealWorld -> (# State# RealWorld, Result u b #) {- Arity: 5, HasNoCafRefs, Strictness: <C(C(C(S(SS)))),1*C1(C1(C1(U(U,1*U))))><L,U><L,U><L,U><S,U>, Unfolding: InlineRule (5, True, False) (\ @ u @ a @ b (ds :: GenHaxl u a) (k :: a -> GenHaxl u b) (env :: Int) (ref :: IORef ()) (s :: State# RealWorld)[OneShot] -> case (ds `cast` (N:GenHaxl[0] <u>_P <a>_R) env ref) `cast` (N:IO[0] <Result u a>_R) s of ds1 { (#,#) ipv ipv1 -> case ipv1 of wild { Done a1 -> ((k a1) `cast` (N:GenHaxl[0] <u>_P <b>_R) env ref) `cast` (N:IO[0] <Result u b>_R) ipv Throw e -> (# ipv, Throw @ u @ b e #) Blocked cont -> (# ipv, Blocked @ u @ b (:>>= @ u @ b @ a cont k) #) } }) -} }}} That right there is the definition of `>>=`. Note that it has an `InlineRule`, which means that it will be unconditionally unfolded pretty much everywhere. I don't think this is right - there's no benefit to be had in inlining it unconditionally. I delved in a bit more, and it seems this unfolding arises during worker- wrapper. Before WW we have {{{ a_sVM [LclId, Arity=5, Str=DmdType <C(C(C(S(SS)))),1*C1(C1(C1(U(U,1*U))))><L,U><L,U><L,U><S,U>, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0 60 0 0 0] 94 60}] a_sVM = \ @ u_XQR @ a_aPN @ b_aPO ds_dQP [Dmd=<C(C(C(S(SS)))),1*C1(C1(C1(U(U,1*U))))>] k_aEC env_aED ref_aEE s_aVC [Dmd=<S,U>, OS=OneShot] -> case (((ds_dQP `cast` ...) env_aED ref_aEE) `cast` ...) s_aVC of _ [Occ=Dead, Dmd=<L,A>] { (# ipv_aVF [Dmd=<S,U>], ipv1_aVG [Dmd=<S,1*U>] #) -> case ipv1_aVG of _ [Occ=Dead, Dmd=<L,A>] { Done a_aEG -> ((((k_aEC a_aEG) `cast` ...) env_aED ref_aEE) `cast` ...) ipv_aVF; Throw e_aEH -> (# ipv_aVF, Haxl.Throw e_aEH #); Blocked cont_aEI -> (# ipv_aVF, Haxl.Blocked (Haxl.:>>= cont_aEI k_aEC) #) } } }}} and after WW we have {{{ a_sVM [LclId, Arity=5, Str=DmdType <C(C(C(S(SS)))),1*C1(C1(C1(U(U,1*U))))><L,U><L,U><L,U><S,U>, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=5,unsat_ok=True,boring_ok=False) Tmpl= \ @ u_XQR @ a_aPN @ b_aPO ds_dQP [Occ=Once] k_aEC [Occ=Once*] env_aED ref_aEE s_aVC [Occ=Once, OS=OneShot] -> case (((ds_dQP `cast` ...) env_aED ref_aEE) `cast` ...) s_aVC of _ [Occ=Dead] { (# ipv_aVF [Occ=Once*], ipv1_aVG [Occ=Once!] #) -> case ipv1_aVG of _ [Occ=Dead] { Done a_aEG [Occ=Once] -> ((((k_aEC a_aEG) `cast` ...) env_aED ref_aEE) `cast` ...) ipv_aVF; Throw e_aEH [Occ=Once] -> (# ipv_aVF, Haxl.Throw e_aEH #); Blocked cont_aEI [Occ=Once] -> (# ipv_aVF, Haxl.Blocked (Haxl.:>>= cont_aEI k_aEC) #) } }}] a_sVM = \ @ u_XQR @ a_aPN @ b_aPO ds_dQP [Dmd=<C(C(C(S(SS)))),1*C1(C1(C1(U(U,1*U))))>] k_aEC env_aED ref_aEE s_aVC [Dmd=<S,U>, OS=OneShot] -> case (((ds_dQP `cast` ...) env_aED ref_aEE) `cast` ...) s_aVC of _ [Occ=Dead, Dmd=<L,A>] { (# ipv_aVF [Dmd=<S,U>], ipv1_aVG [Dmd=<S,1*U>] #) -> case ipv1_aVG of _ [Occ=Dead, Dmd=<L,A>] { Done a_aEG -> ((((k_aEC a_aEG) `cast` ...) env_aED ref_aEE) `cast` ...) ipv_aVF; Throw e_aEH -> (# ipv_aVF, Haxl.Throw e_aEH #); Blocked cont_aEI -> (# ipv_aVF, Haxl.Blocked (Haxl.:>>= cont_aEI k_aEC) #) } } }}} For some unknown reason, this binding has acquired an always-on unfolding. There's no wrapper, we're just unfolding the whole thing. Simon, can you shed any light here? I would like to tune unfolding sizes to reduce code bloat in our codebase, but with this unfolding being unconditional it doesn't work to use `-funfolding-use-threshold`, I can only use `NOINLINE` but that's too blunt. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11564> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #12534: GHC 8.0 accepts recursive kind signature that GHC 7.10 rejects
by GHC 03 Jan '17

03 Jan '17

#12534: GHC 8.0 accepts recursive kind signature that GHC 7.10 rejects -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 7.10 rejects this datatype: {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} module Bug where data T (a :: a) }}} {{{ $ /opt/ghc/7.10.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:1: Kind variable also used as type variable: ‘a’ In the data type declaration for ‘T’ }}} But GHC 8.0 accepts the above code! It appears that GHC implicitly freshens the kind-level `a` so as to have a different name, since the following modification to `T`: {{{#!hs data T a (a :: a) }}} Results in this error: {{{ $ /opt/ghc/8.0.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:8: error: Conflicting definitions for ‘a’ Bound at: Bug.hs:5:8 Bug.hs:5:11 Bug.hs:5:16: error: Type variable ‘a’ used in a kind. Did you mean to use TypeInType? the data type declaration for ‘T’ }}} But with this modification: {{{#!hs data T (a :: a) a }}} You won't get an error message about `a` being used as both a kind and type: {{{ $ /opt/ghc/8.0.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:9: error: Conflicting definitions for ‘a’ Bound at: Bug.hs:5:9 Bug.hs:5:17 }}} To make things even more confusing, this behavior doesn't seem to carry over to typeclass instances. For example: GHC 8.0 will (rightfully) reject this code: {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} module Bug where data T (a :: a) class C x instance C (T (a :: a)) }}} {{{ $ /opt/ghc/8.0.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:16: error: Variable ‘a’ used as both a kind and a type Did you intend to use TypeInType? }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12534> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12241: Surprising constructor accumulation
by GHC 30 Dec '16

30 Dec '16

#12241: Surprising constructor accumulation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | 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: -------------------------------------+------------------------------------- `containers` version 0.5.7.1 (and a few earlier versions) uses the following implementation of `fromList` by Ross Paterson: {{{#!hs fromList :: [a] -> Seq a fromList = Seq . mkTree 1 . map_elem where {-# SPECIALIZE mkTree :: Int -> [Elem a] -> FingerTree (Elem a) #-} {-# SPECIALIZE mkTree :: Int -> [Node a] -> FingerTree (Node a) #-} mkTree :: (Sized a) => Int -> [a] -> FingerTree a mkTree !_ [] = EmptyT mkTree _ [x1] = Single x1 mkTree s [x1, x2] = Deep (2*s) (One x1) EmptyT (One x2) mkTree s [x1, x2, x3] = Deep (3*s) (One x1) EmptyT (Two x2 x3) mkTree s (x1:x2:x3:x4:xs) = case getNodes (3*s) x4 xs of (ns, sf) -> case mkTree (3*s) ns of !m -> Deep (3*size x1 + size m + size sf) (Three x1 x2 x3) m sf getNodes :: Int -> a -> [a] -> ([Node a], Digit a) getNodes !_ x1 [] = ([], One x1) getNodes _ x1 [x2] = ([], Two x1 x2) getNodes _ x1 [x2, x3] = ([], Three x1 x2 x3) getNodes s x1 (x2:x3:x4:xs) = (Node3 s x1 x2 x3:ns, d) where (ns, d) = getNodes s x4 xs map_elem :: [a] -> [Elem a] #if __GLASGOW_HASKELL__ >= 708 map_elem xs = coerce xs #else map_elem xs = Data.List.map Elem xs #endif {-# INLINE map_elem #-} }}} This uses one lazy list per "level" in the tree being constructed. I believe Paterson (and pretty much everyone else) expected that there would be `O(log n)` pair constructors and conses live at any given time. Wadler's technique in [http://homepages.inf.ed.ac.uk/wadler/papers/leak/leak.ps.gz Fixing some space leaks with a garbage collector], which the GHC commentary indicates is used in GHC, should clean up the pairs in `getNodes`'s `d` thunks as they reach WHNF. Lennart Spitzner dug into the unimpressive performance of the above code and using {{{#!hs main = evaluate $ S.fromList [(0::Int)..999999] }}} produced [http://heap.ezyang.com/view/72d4d1eb879a2085ffd49d270b03c7a037b4d5c2 this heap profile]. If I'm reading it right, this suggests that there are lots of `(,)` and also `(:)` constructors live, more `O(n)` than `O(log n)`. I had previously found that I could improve performance by building the intermediate lists strictly, but that violates the generational hypothesis and leads to a slow-down for very large arguments ([http://heap.ezyang.com/view/2e80598f73d9281f5eadfeb041f5b9aef6e448b0 Spitzner's heap profile]). Spitzner was able to come up with a very clever (but much trickier) implementation that skirted all these problems ([http://heap.ezyang.com/view/7f1994c0417931360fe7c41bd995c37ebc3fd6c5 profile]) and avoids ever allocating the troublesome pairs. So the problem is thoroughly bypassed for `containers`, but it seems like something is not quite right here, and it might bear looking into. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12241> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11216: RebindableSyntax with pattern guards needs `fail`
by GHC 26 Dec '16

26 Dec '16

#11216: RebindableSyntax with pattern guards needs `fail` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- If I say {{{ {-# LANGUAGE RebindableSyntax #-} module Bug where foo :: (a, b) -> () foo x | (_,_) <- x = () }}} I get {{{ Bug.hs:6:9: error: Not in scope: ‘fail’ }}} Yet even if I bring `fail` into scope, it's not mentioned in the Core produced by my program. And it really shouldn't: there's not a monad in sight! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11216> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8107: need types to express constant argument for primop correctness
by GHC 22 Dec '16

22 Dec '16

#8107: need types to express constant argument for primop correctness ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- (not sure if this is a bug or a feature request, or a task, or a dialogue, filing as a bug for now) a number of compiler intrinsics that GHC has started to support (prefetch) and will come to support (concurrent memory operations a la http://ghc.haskell.org/trac/ghc/ticket/7883) require certain arguments to be statically fixed at compile time {{{ primop PrefetchAddrOp "prefetchAddr#" GenPrimOp Addr# -> Int# -> Addr# with llvm_only = True }}} consider the specification on the llvm side for prefetch http://llvm.org/docs/LangRef.html#llvm-prefetch-intrinsic {{{ Syntax:¶ declare void @llvm.prefetch(i8* <address>, i32 <rw>, i32 <locality>, i32 <cache type>) Overview: The ‘llvm.prefetch‘ intrinsic is a hint to the code generator to insert a prefetch instruction if supported; otherwise, it is a noop. Prefetches have no effect on the behavior of the program but can change its performance characteristics. Arguments: address is the address to be prefetched, rw is the specifier determining if the fetch should be for a read (0) or write (1), and locality is a temporal locality specifier ranging from (0) - no locality, to (3) - extremely local keep in cache. The cache type specifies whether the prefetch is performed on the data (1) or instruction (0) cache. The rw, locality and cache type arguments must be constant integers. }}} the punch line is that we're starting add primops that REALLY require certain arguments to be compile time constants to work correctly, otherwise there will by definition be compiler errors after the c-- phase when operations are passed along to the llvm backend and friends. (for the atomicity ops, i'll be looking into adding them to the native code gen, but the point being it will likely trigger an error at code gen time). a strawman approach would look like adding a type {{{ ReallyActuallyConstant :: * or unliftedtype -> * unliftedtype}}} roughly, then prefetch could have the type {{{ primop PrefetchAddrOp "prefetchAddr#" GenPrimOp Addr# ->ReallyActuallyConstant Int# -> Addr# with llvm_only = True }}} a way of emulating something like this functionality now, would be some template haskell that lets you lift a compile time constant of type t into the type ReallyActuallyConstant t, and is the only way to build a value of that type "ReallyActuallyConstant t". That said, that approach seems like a bad way of providing type safetype for making sure primops actually compile! Point being, some sort of way of nicely enforcing that a value needs to be available at compile time, that doesn't require doing abusing template haskell, is the idea i'm pointing at. Might also be useful for other things, but for now, i'm merely remarking on an invariant these primops have -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8107> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12485: -package-db flags now need to be sorted by dependency order
by GHC 21 Dec '16

21 Dec '16

#12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 8.0.1 system | 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: -------------------------------------+------------------------------------- After 39b71e81ec1044518f065d0055676d713521e483 putting the -package-db flags in the wrong order will result in a compile error: {{{ <command line>: cannot satisfy -package-id b-1-XXX: b-1-XXX is unusable due to missing or recursive dependencies: a-1-XXX (use -v for more information) }}} See attached file for a repro. It's reproduces in 8.0.1 and HEAD. Doesn't reproduce in GHC 7.10.3 or after reverting the above mentioned commit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12485> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 39

[GHC] #9509: No automatic specialization of inlinable imports in 7.8
by GHC 21 Dec '16

21 Dec '16

#9509: No automatic specialization of inlinable imports in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: -------------------------------------+------------------------------------- According to the GHC manual, any uses of an imported definition that is overloaded and INLINABLE will automatically cause a SPECIALIZE to be generated for those uses, if appropriate. However, this no longer appears to be the case in 7.8(.3). Here is a simple test case: {{{#!hs module A (foo) where import Data.IORef foo :: Ord a => a -> IO a foo x = newIORef x >>= readIORef >>= \y -> case compare x y of LT -> return x ; _ -> return y {-# INLINABLE foo #-} }}} {{{#!hs module Main (main) where import A main = foo (5 :: Int) >>= print }}} `foo` is constructed to be long enough that GHC 7.8.3 will elect to not inline it. When compiling with 7.6.3, the core contains the following: {{{ Main.$sfoo1 :: GHC.Types.Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Types.Int #) [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType LL, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=2, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 0] 55 30}] Main.$sfoo1 = \ (x_XkE :: GHC.Types.Int) (eta_B1 :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.newMutVar# @ GHC.Types.Int @ GHC.Prim.RealWorld x_XkE eta_B1 of _ { (# ipv_amT, ipv1_amU #) -> case GHC.Prim.readMutVar# @ GHC.Prim.RealWorld @ GHC.Types.Int ipv1_amU ipv_amT of ds1_amJ { (# ipv2_Xn8, ipv3_Xna #) -> case x_XkE of wild_axu { GHC.Types.I# x#_axw -> case ipv3_Xna of _ { GHC.Types.I# y#_axA -> case GHC.Prim.<# x#_axw y#_axA of _ { GHC.Types.False -> ds1_amJ; GHC.Types.True -> (# ipv2_Xn8, wild_axu #) } } } } } Main.$sfoo :: GHC.Types.Int -> GHC.Types.IO GHC.Types.Int [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType LL, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True)}] Main.$sfoo = Main.$sfoo1 `cast` (<GHC.Types.Int> -> Sym <(GHC.Types.NTCo:IO <GHC.Types.Int>)> :: (GHC.Types.Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Types.Int #)) ~# (GHC.Types.Int -> GHC.Types.IO GHC.Types.Int)) ... ------ Local rules for imported ids -------- "SPEC A.foo [GHC.Types.Int]" [ALWAYS] forall ($dOrd_sxj :: GHC.Classes.Ord GHC.Types.Int) A.foo @ GHC.Types.Int $dOrd_sxj = Main.$sfoo }}} However, in 7.8.3 and newer (I'm actually using 7.9.20140725 for this particular output, but 7.8.3 is similar), we see the following: {{{ Main.main1 :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) [GblId, Arity=1, Str=DmdType <L,U>, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 100 0}] Main.main1 = \ (s_aIb :: GHC.Prim.State# GHC.Prim.RealWorld) -> case ((A.foo @ GHC.Types.Int GHC.Classes.$fOrdInt Main.main2) `cast` (GHC.Types.NTCo:IO[0] <GHC.Types.Int>_R :: GHC.Types.IO GHC.Types.Int ~R# (GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Types.Int #)))) s_aIb of _ [Occ=Dead] { (# ipv_aIe, ipv1_aIf #) -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout (GHC.Show.$fShowInt_$cshow ipv1_aIf) GHC.Types.True ipv_aIe } }}} There is no local rules section in 7.8.3. Putting a manual SPECIALIZE pragma in the main module generates comparable code to 7.6.3, so it does not appear to be a failure at that level. Rather, GHC seems to just not be generating the SPECIALIZE equivalent. Presumably this is a regression, but even if not, the manual should be revised. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9509> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11598: Cache coercion kinds and roles
by GHC 21 Dec '16

21 Dec '16

#11598: Cache coercion kinds and roles -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Because we never inspect the structure of a coercion, it is easy to cache coercions' kinds and role at the top level, using something like this: {{{ data Coercion = MkCoercion { coercionKind :: Pair Type , coercionRole :: Role , coercionRep :: CoercionRep } data CoercionRep = -- the long, recursive datatype we have now }}} In the process, various role and type information currently stored in the recursive structure could be dropped. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11598> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12444: Regression: panic! on inaccessible code with constraint
by GHC 21 Dec '16

21 Dec '16

#12444: Regression: panic! on inaccessible code with constraint -------------------------------------+------------------------------------- Reporter: zilinc | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running the following program with ghci-8.0.1: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module Prove where data Nat = Zero | Succ Nat data SNat (n :: Nat) where SZero :: SNat Zero SSucc :: SNat n -> SNat (Succ n) type family (:+:) (a :: Nat) (b :: Nat) :: Nat where m :+: Zero = m m :+: (Succ n) = Succ (m :+: n) sadd :: ((Succ n1 :+: n) ~ Succ (n1 :+: n), (Succ n1) ~ m) => SNat m -> SNat n -> SNat (m :+: n) sadd SZero n = n }}} -ddump-tc-trace shows: {{{ ... dischargeFmv s_a9qV[fuv:4] = t_a9qW[tau:5] (1 kicked out) doTopReactFunEq (occurs) old_ev: [D] _ :: ((n1_a9qu[sk] :+: 'Succ s_a9qV[fuv:4]) :: Nat) GHC.Prim.~# (s_a9qV[fuv:4] :: Nat)ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): ctEvCoercion [D] _ :: (t_a9qW[tau:5] :: Nat) ~# ('Succ (n1_a9qu[sk] :+: s_a9qV[fuv:4]) :: Nat) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It is rightly rejected by ghci-7.10.2: {{{ Prove.hs:42:6: Couldn't match type ‘'Succ n1’ with ‘'Zero’ Inaccessible code in a pattern with constructor SZero :: SNat 'Zero, in an equation for ‘sadd’ In the pattern: SZero In an equation for ‘sadd’: sadd SZero n = n Failed, modules loaded: none. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12444> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7