December 2016 - ghc-tickets

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

21 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] #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker
by GHC 21 Dec '16

21 Dec '16

#13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: SpecConstr | 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: -------------------------------------+------------------------------------- !SpecConstr creates the following rules, with the right cajoling. (I've used unboxed integers merely to avoid w/w, which only adds noise in this example.) {{{#!hs data VL :: [k] -> * where VLZ :: VL '[] VLS :: VL as -> VL (a ': as) lengthVL :: GHC.Types.SPEC -> VL as -> Int# {-# INLINABLE lengthVL #-} lengthVL !sPEC VLZ = 0# lengthVL !sPEC (VLS vl) = 1# +# lengthVL sPEC vl ==================== Tidy Core rules ==================== "SC:lengthVL0" [ALWAYS] forall (@ a) (@ (as :: [*])) (sc :: VL as). lengthVL @ (a : as) SPEC (VLS @ * @ (a : as) @ as @ a @~ (<a : as>_N :: (a : as) ~ (a : as)) sc) = lengthVL_$slengthVL1 @ a @ as sc "SC:lengthVL1" [ALWAYS] forall (sc :: VL '[]). lengthVL @ '[] SPEC sc = lengthVL_$slengthVL sc }}} But the cons-case specialization, `lengthVL_$slengthVL1`, is marked as a loopbreaker. Consider the following idiomatic usage to see why that is problematic. {{{#!hs class KnownSpine (as :: [k]) where sing :: VL as instance KnownSpine '[] where -- ' {-# INLINE sing #-} sing = VLZ instance KnownSpine as => KnownSpine (a ': as) where -- ' {-# INLINE sing #-} sing = VLS sing example :: Int example = I# $ lengthVL SPEC (sing :: VL '[Int,Char,Bool]) }}} The right-hand side of `example` would ideally be simplified to `3`. It's not, ultimately because the specialization is marked as a loopbreaker. I switched on `-dverbose-core2core` to track the simplification of the right-hand side of `example`. 1) The `sing` dictionary is unfolded to constructor applications. 2) Those are floated out but then pre-inlined- unconditionally right back in before CSE gets a chance to spoil it. 3) Thus the VLS rule fires. But it only fires once, because of the loopbreaker designation! I have not yet investigated why the specialization in the cons-case is marked a loopbreaker. (Even if the specialization wasn't being considered a loopbreaker --- which immediately makes this approach to optimization a dead-end --- I don't know with any certainty how to force the specialization to be inlined in those cases where its right-hand side was relatively large.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13014> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13024: T12877 intermittently fails
by GHC 21 Dec '16

21 Dec '16

#13024: T12877 intermittently fails -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Test Suite | 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 recently ran a validate where this failed: {{{ bytes allocated value is too high: Expected T12877(normal) bytes allocated: 135979000 +/-5% Lower bound T12877(normal) bytes allocated: 129180050· Upper bound T12877(normal) bytes allocated: 142777950· Actual T12877(normal) bytes allocated: 143317872· Deviation T12877(normal) bytes allocated: 5.4 % *** unexpected stat test failure for T12877(normal) }}} When I reran the test by itself, it passed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13024> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[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] #13023: strange behaviour of GHCi when int value exceed int range
by GHC 21 Dec '16

21 Dec '16

#13023: strange behaviour of GHCi when int value exceed int range -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- import Data.Char type Bit = Int int2bin :: Int -> [Bit] int2bin 0 = [] int2bin n = reverse (n `mod`2 : (reverse (int2bin (n `div`2)))) When n = 4200000000, GHCi crash with "out of memory" but if n = 4300000000 GHCi send a result as [1,0,0,1,1,0,0,1,1,0,0,1,0,1,1,0,0,0,0,0,0,0,0] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13023> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12969: Rebindable enumFrom etc. syntax
by GHC 21 Dec '16

21 Dec '16

#12969: Rebindable enumFrom etc. syntax -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple RebindableSyntax | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Constructs like `[x..]` or `[x..y]` etc. seem to use wired-in `enumFrom`, `enumFromTo`, etc. names even when `RebindableSyntax` is turned on. I think we should allow these to be shadowed by the user the same way they can shadow other syntax desugarings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12969> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12950: unnecessarily complicated left-hand side causing RULE left-hand side too complicated to desugar
by GHC 21 Dec '16

21 Dec '16

#12950: unnecessarily complicated left-hand side causing RULE left-hand side too complicated to desugar -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #10555,#12074 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 7.10.2 rejects the `SPECIALIZE` pragma in the following snippet with "RULE left-hand side too complicated to desugar". {{{#!hs class C a where type TF a; m :: a -> TF a instance C Int where type TF Int = String; m = show overloaded :: C a => a -> (a,TF a) {-# INLINABLE overloaded #-} overloaded a = (a,m a) {-# SPECIALIZE overloaded :: Int -> (Int,TF Int) #-} }}} This use case is so simple/basic/prevalent that it seems inappropriate to reject it. The actual message is {{{ RULE left-hand side too complicated to desugar Optimised lhs: case cobox_awc of _ [Occ=Dead] { GHC.Types.Eq# cobox -> overloaded @ Int $dC_awb } Orig lhs: case cobox_awc of cobox_awc { GHC.Types.Eq# cobox -> overloaded @ Int $dC_awb } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12950> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12968: GHC crash with TypeInType and pattern synonym
by GHC 21 Dec '16

21 Dec '16

#12968: GHC crash with TypeInType and pattern synonym -------------------------------------+------------------------------------- Reporter: dfeuer | 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 or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I decided to try playing with the proposed new `Typeable` interface, faking up types and functions in GHC 8.0.1. Unfortunately, it seems I did something impossible: {{{#!hs {-# LANGUAGE TypeInType, GADTs, ScopedTypeVariables, PatternSynonyms, ViewPatterns #-} module TypeReflection where data TypeRep (a :: k) data TRAppG (fun :: k2) where TRAppG :: forall k1 (a :: k1 -> k2) (b :: k1) . TypeRep a -> TypeRep b -> TRAppG (a b) pattern TRApp :: forall k2 (fun :: k2). () => forall k1 (a :: k1 -> k2) (b :: k1). (fun ~ a b) => TypeRep a -> TypeRep b -> TypeRep fun pattern TRApp a b <- ((undefined :: TypeRep fun -> TRAppG fun) -> TRAppG a b) }}} The error: {{{ [1 of 1] Compiling TypeReflection ( TypeReflectionTemplate.hs, TypeReflectionTemplate.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): StgCmmEnv: variable not found $dIP_a1Aj local binds for: typeRep $tcTypeable $tc'C:Typeable $tcTypeRep $tc'TRAppG $WTRAppG $tcTRAppG $trModule $tcTRAppG1_r1KE $tc'TRAppG1_r1KS $tcTypeRep1_r1KT $tcTypeable1_r1KU $tc'C:Typeable1_r1KV $trModule1_r1KW $trModule2_r1KX scrut_s1Lg cont_s1Lh fail_s1Li sat_s1Lj sat_s1Lk sat_s1Ll sat_s1Lm sat_s1Ln sat_s1Lo sat_s1Lp sat_s1Lq sat_s1Lr sat_s1Ls sat_s1Lt }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12968> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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