- ghc-tickets - Haskell.org

Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
by GHC 21 Sep '17

21 Sep '17

#6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Ok, so is it something that should be addressed in the LLVM code generator, or do we need to also retain more information in Cmm? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6084#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13959: substTyVar's definition is highly dubious
by GHC 21 Sep '17

21 Sep '17

#13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Currently, we have: {{{#!hs substTyVar :: TCvSubst -> TyVar -> Type substTyVar (TCvSubst _ tenv _) tv = ASSERT( isTyVar tv ) case lookupVarEnv tenv tv of Just ty -> ty Nothing -> TyVarTy tv }}} But as Richard pointed out to me, the `Nothing` case is flat-out wrong. If `tv` isn't in the substitution, we need to check if any of the variables in `tv`'s kind are in the substitution, and if so, apply the substitution to them. Fixing this might seem straightforward enough: {{{#!diff diff --git a/compiler/types/TyCoRep.hs b/compiler/types/TyCoRep.hs index 5ac63e5..4f7d650 100644 --- a/compiler/types/TyCoRep.hs +++ b/compiler/types/TyCoRep.hs @@ -2191,11 +2191,11 @@ subst_ty subst ty go (CoercionTy co) = CoercionTy $! (subst_co subst co) substTyVar :: TCvSubst -> TyVar -> Type -substTyVar (TCvSubst _ tenv _) tv +substTyVar subst@(TCvSubst _ tenv _) tv = ASSERT( isTyVar tv ) case lookupVarEnv tenv tv of Just ty -> ty - Nothing -> TyVarTy tv + Nothing -> TyVarTy (updateTyVarKind (substTyUnchecked subst) tv) substTyVars :: TCvSubst -> [TyVar] -> [Type] substTyVars subst = map $ substTyVar subst }}} But note that I'm using `substTyUnchecked`, not `substTy`, since if you try using the latter, GHC will pretty quickly fall over on a `./validate --slow` build, as `substTy`'s assertions are violated all over the place. I'm fairly certain I know why the assertions would be tripping up, however. To build most of the in-scope sets used for `substTyVar`'s substitutions, the `mkVarSet :: [Var] -> VarSet` function is used. But `mkVarSet` only grabs the `Unique`s of the type variables themselves, not the variables in the kind of each type variable. This means the in-scope sets will frequently be too narrow to encompass the kind variables, which absolutely must be in the set if we want to change `substTyVar` as described above. I'm not sure what the solution is here. Perhaps we should be using a variant of `mkVarSet` called `mkTyVarSet` that grabs the `Unique`s of the kind variables as well? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13959> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #14243: GHC doesn't add constraint when deriving
by GHC 21 Sep '17

21 Sep '17

#14243: GHC doesn't add constraint when deriving -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- I can't remember if this was intended, but GHC cannot `derive newtype Functor` or `derive stock Functor` for `WGeneric` even if it knows the constraint to add (I have `FlexibleInstances` enabled) {{{#!hs import GHC.Generic -- • Could not deduce (Functor (Rep1 f)) -- arising from the 'deriving' clause of a data type declaration -- from the context: Functor f -- bound by the deriving clause for ‘Functor (WGeneric f)’ -- at /home/baldur/hs/074.hs:63:5-11 -- Possible fix: -- use a standalone 'deriving instance' declaration, -- so you can specify the instance context yourself newtype WGeneric f a = WGeneric (Sum (Rep1 f) f a) deriving newtype Functor }}} but either of these works {{{#!hs deriving newtype instance (Functor f, Functor (Rep1 f)) => Functor (WGeneric f) deriving stock instance (Functor f, Functor (Rep1 f)) => Functor (WGeneric f) }}} Could GHC add the inferred `Functor (Rep1 f)`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14243> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14258: n-body runtime regressed badly due to CoreFVs patch
by GHC 20 Sep '17

20 Sep '17

#14258: n-body runtime regressed badly due to CoreFVs patch -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- While looking through nofib numbers I noticed that `n-body` regressed in runtime by around 20% due to 751996e90a964026a3f86853338f10c82db6b610. Yikes! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14258> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8919: Why is xhtml library installed but not exported to users?
by GHC 20 Sep '17

20 Sep '17

#8919: Why is xhtml library installed but not exported to users? ------------------------------------+------------------------------------- Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC 7.8.1-rc2 installs the xhtml library, but doesn't export it, i.e. it's completely invisible to users. Is there a particular reason why this setup is necessary? If GHC needs that library internally anywhere, would it be possible to link it statically and *not* install it? Or, if that's not possible, if the library needs to be installed, please make it visible to users. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8919> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #14240: CSE’ing w/w’ed code regresses program runtime
by GHC 20 Sep '17

20 Sep '17

#14240: CSE’ing w/w’ed code regresses program runtime -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- Commit changeset:fe04f378/ghc, which fixed #14186, causes two runtime regressions: {{{ nofib/time/integer 1.529 + 4.19% 1.593 seconds nofib/time/lambda 1.041 + 7.3% 1.117 seconds }}} Sigh. I guess it up to me to track that one down. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14240> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14224: zipWith does not inline
by GHC 20 Sep '17

20 Sep '17

#14224: zipWith does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core | Version: 8.2.1 Libraries | 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: -------------------------------------+------------------------------------- `zipWith` is currently defined {{{#!hs zipWith :: (a->b->c) -> [a]->[b]->[c] zipWith _f [] _bs = [] zipWith _f _as [] = [] zipWith f (a:as) (b:bs) = f a b : zipWith f as bs }}} For now (I gather that might change soon?), the fact that it's recursive means that it will never inline. But we really want it to inline when applied to a function, for the same reasons we want `map` to inline. If `f` is something like `const`, `flip const`, or a lazy constructor, it's wasteful to create a thunk to apply it. All three of those cases are common. So unless/until we start inlining recursive functions, we probably want to use {{{#!hs zipWith f = go where go [] _ = [] go _ [] = [] go (x:xs) (y:ys) = f x y : go xs ys }}} There will probably be some regressions, of course. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions
by GHC 20 Sep '17

20 Sep '17

#9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries (other) | Version: Keywords: integer-gmp | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- After some promising results with a proof-of-concept implementation, I'm optimistic we can rewrite `integer-gmp` to use only non-allocating GMP lib functions without suffering from serious regressions. If successful, this would - allow to avoid the custom GMP allocator hack, and thus - avoid issues when linking against other C libraries using GMP, - simplify code, as we would perform all heap allocations in Haskell code (and never inside Cmm/C code as its done now), - and finally maybe even remove a few more superfluous temporary heap allocations. This rewrite can be done incrementally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9281> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 32

[GHC] #14197: Flag "dump-rn-ast" only dumps the declarations, not the whole RenamedSource
by GHC 20 Sep '17

20 Sep '17

#14197: Flag "dump-rn-ast" only dumps the declarations, not the whole RenamedSource -------------------------------------+------------------------------------- Reporter: alanz | 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: -------------------------------------+------------------------------------- `RenamedSource` is defined as {{{#!hs type RenamedSource = ( HsGroup Name , [LImportDecl Name] , Maybe [LIE Name] , Maybe LHsDocString) }}} The current behaviour when `dump-rn-ast` is set is to only dump the first component of this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14197> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13481: T12622 fails in ghci way
by GHC 20 Sep '17

20 Sep '17

#13481: T12622 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- `T12622`, which is intended to test StaticPointers, fails in the GHCi way with a core lint warning, {{{ *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) *** <no location info>: warning: In the expression: >>= @ IO $fMonadIO @ (Bool -> Bool) @ () (break<10>(s_a1DF) lvl_s3bD) lvl_s3bE s_a1DF :: StaticPtr (Bool -> Bool) [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 70 0}] is out of scope *** Offending Program *** g :: Bool [LclIdX] g = break<15>() True $trModule_s3b7 :: Addr# [LclId] $trModule_s3b7 = "main"# $trModule_s3b6 :: TrName [LclId] $trModule_s3b6 = TrNameS $trModule_s3b7 $trModule_s3b9 :: Addr# [LclId] $trModule_s3b9 = "Main"# $trModule_s3b8 :: TrName [LclId] $trModule_s3b8 = TrNameS $trModule_s3b9 $trModule :: Module [LclIdX] $trModule = Module $trModule_s3b6 $trModule_s3b8 lvl_s3bj :: Addr# [LclId] lvl_s3bj = "error"# lvl_s3bk :: [Char] [LclId] lvl_s3bk = unpackCString# lvl_s3bj lvl_s3bl :: Addr# [LclId] lvl_s3bl = "main"# lvl_s3bm :: [Char] [LclId] lvl_s3bm = unpackCString# lvl_s3bl lvl_s3bn :: Addr# [LclId] lvl_s3bn = "Main"# lvl_s3bo :: [Char] [LclId] lvl_s3bo = unpackCString# lvl_s3bn lvl_s3bp :: Addr# [LclId] lvl_s3bp = "T12622.hs"# lvl_s3bq :: [Char] [LclId] lvl_s3bq = unpackCString# lvl_s3bp lvl_s3br :: Int [LclId] lvl_s3br = I# 21# lvl_s3bs :: Int [LclId] lvl_s3bs = I# 14# lvl_s3bt :: Int [LclId] lvl_s3bt = I# 21# lvl_s3bu :: Int [LclId] lvl_s3bu = I# 64# lvl_s3bv :: SrcLoc [LclId] lvl_s3bv = SrcLoc lvl_s3bm lvl_s3bo lvl_s3bq lvl_s3br lvl_s3bs lvl_s3bt lvl_s3bu lvl_s3bw :: ([Char], SrcLoc) [LclId] lvl_s3bw = (lvl_s3bk, lvl_s3bv) $dIP_s3bc :: CallStack [LclId] $dIP_s3bc = pushCallStack lvl_s3bw emptyCallStack lvl_s3bx :: Addr# [LclId] lvl_s3bx = "couldn't find "# lvl_s3by :: [Char] [LclId] lvl_s3by = unpackCString# lvl_s3bx lookupKey :: forall a. StaticPtr a -> IO a [LclIdX, Arity=1] lookupKey = \ (@ a_a23X) (p_X1DX :: StaticPtr a_a23X) -> break<8>(p_X1DX) >>= @ IO $fMonadIO @ (Maybe (StaticPtr a_a23X)) @ a_a23X (break<1>(p_X1DX) unsafeLookupStaticPtr @ a_a23X (break<0>(p_X1DX) staticKey @ a_a23X p_X1DX)) (\ (ds_d3as :: Maybe (StaticPtr a_a23X)) -> case ds_d3as of { Nothing -> break<7>(p_X1DX) error @ 'LiftedRep @ (IO a_a23X) ($dIP_s3bc `cast` (Sym (N:IP[0] <"callStack">_N <CallStack>_N) :: (CallStack :: *) ~R# ((?callStack::CallStack) :: Constraint))) (break<6>(p_X1DX) ++ @ Char lvl_s3by (break<5>(p_X1DX) show @ StaticPtrInfo $fShowStaticPtrInfo (break<4>(p_X1DX) staticPtrInfo @ a_a23X p_X1DX))); Just p_a1DI -> break<3>(p_a1DI) return @ IO $fMonadIO @ a_a23X (break<2>(p_a1DI) deRefStaticPtr @ a_a23X p_a1DI) }) $dTypeable_s3bA :: TypeRep Bool [LclId] $dTypeable_s3bA = mkTrCon @ * @ Bool $tcBool ([] @ SomeTypeRep) s_s3bC :: StaticPtr (Bool -> Bool) [LclId] s_s3bC = case break<9>() sg @ Bool ($dTypeable_s3bA `cast` (Sym N:Typeable[0] <*>_N <Bool>_N :: (TypeRep Bool :: *) ~R# (Typeable Bool :: Constraint))) of { T s_a38b -> s_a38b } lvl_s3bD :: IO (Bool -> Bool) [LclId] lvl_s3bD = lookupKey @ (Bool -> Bool) s_s3bC lvl_s3bE :: (Bool -> Bool) -> IO () [LclId] lvl_s3bE = \ (f_a1DG :: Bool -> Bool) -> break<12>(f_a1DG) print @ Bool $fShowBool (break<11>(f_a1DG) f_a1DG True) main :: IO () [LclIdX] main = break<14>() break<13>(s_s3bC) >>= @ IO $fMonadIO @ (Bool -> Bool) @ () (break<10>(s_a1DF) lvl_s3bD) lvl_s3bE main :: IO () [LclIdX] main = runMainIO @ () main *** End of Offense *** <no location info>: error: Compilation had errors *** Exception: ExitFailure 1 ===== program output begins here ===== program output begins here T12622:6:30: error: Not in scope: ‘Main.main’ No module named ‘Main’ is imported. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13481> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12