January 2016 - ghc-tickets

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper
by GHC 17 Jan '16

17 Jan '16

#5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: | 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: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > If a function marked as `INLINABLE` is called indirectly through a simple > wrapper defined in a different module, specialization never happens (i.e. > none of the dictionaries are removed.) > > Here's an example where it fails. First, the simple wrapper module: > > {{{ > module Repro where > > import Data.Hashable > import Data.HashMap.Strict as M > > infixl 9 ! > (!) :: (Eq a, Hashable a) => M.HashMap a b -> a -> b > m ! x = case M.lookup x m of -- lookup is INLINABLE > Just y -> y > Nothing -> error "Repro.!" > }}} > > and then the call site: > > {{{ > module Test (test) where > > import Data.HashMap.Strict as M > > import Repro > > test :: M.HashMap Int Int -> Int > test m = m ! 42 > }}} > > To compile the code you need to `cabal install unordered-containers`. The > relevant function (which is not getting specialized) from unordered- > containers is: > > {{{ > lookup :: (Eq k, Hashable k) => k -> HashMap k v -> Maybe v > lookup k0 = go h0 k0 0 > where > h0 = hash k0 > go !_ !_ !_ Empty = Nothing > go h k _ (Leaf hx (L kx x)) > | h == hx && k == kx = Just x > | otherwise = Nothing > go h k s (BitmapIndexed b v) > | b .&. m == 0 = Nothing > | otherwise = go h k (s+bitsPerSubkey) (A.index v (sparseIndex > b m)) > where m = mask h s > go h k s (Full v) = go h k (s+bitsPerSubkey) (A.index v (index h s)) > go h k _ (Collision hx v) > | h == hx = lookupInArray k v > | otherwise = Nothing > #if __GLASGOW_HASKELL__ >= 700 > {-# INLINABLE lookup #-} > #endif > }}} > > If `test` calls `lookup` directly, without using the `(!)` wrapper, > things get specialized. Manually marking `(!)` as `INLINABLE` works, but > users shouldn't have to do that. > > The core for `Repro` and `Test` is: > > {{{ > $ ghc -O2 Test.hs -fforce-recomp -ddump-simpl > [1 of 2] Compiling Repro ( Repro.hs, Repro.o ) > > ==================== Tidy Core ==================== > Result size = 28 > > lvl_rNZ :: [GHC.Types.Char] > [GblId] > lvl_rNZ = GHC.CString.unpackCString# "Repro.!" > > Repro.!1 :: forall b_aBU. b_aBU > [GblId, Str=DmdType b] > Repro.!1 = \ (@ b_aBU) -> GHC.Err.error @ b_aBU lvl_rNZ > > Repro.! > :: forall a_atJ b_atK. > (GHC.Classes.Eq a_atJ, Data.Hashable.Hashable a_atJ) => > Data.HashMap.Base.HashMap a_atJ b_atK -> a_atJ -> b_atK > [GblId, > Arity=4, > Str=DmdType LLLL, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=4, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [0 0 0 0] 70 0}] > Repro.! = > \ (@ a_aBT) > (@ b_aBU) > ($dEq_aBV :: GHC.Classes.Eq a_aBT) > ($dHashable_aBW :: Data.Hashable.Hashable a_aBT) > (m_atL :: Data.HashMap.Base.HashMap a_aBT b_aBU) > (x_atM :: a_aBT) -> > case Data.HashMap.Base.lookup > @ a_aBT @ b_aBU $dEq_aBV $dHashable_aBW x_atM m_atL > of _ { > Data.Maybe.Nothing -> Repro.!1 @ b_aBU; > Data.Maybe.Just y_atN -> y_atN > } > > > [2 of 2] Compiling Test ( Test.hs, Test.o ) > > ==================== Tidy Core ==================== > Result size = 20 > > Test.test2 :: GHC.Types.Int > [GblId, > Caf=NoCafRefs, > Str=DmdType m, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [] 10 110}] > Test.test2 = GHC.Types.I# 42 > > Test.test1 > :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int > -> Data.Maybe.Maybe GHC.Types.Int > [GblId, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, > ConLike=False, Cheap=False, Expandable=False, > Guidance=IF_ARGS [] 40 0}] > Test.test1 = > Data.HashMap.Base.lookup > @ GHC.Types.Int > @ GHC.Types.Int > GHC.Classes.$fEqInt > Data.Hashable.$fHashableInt > Test.test2 > > Test.test > :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int > -> GHC.Types.Int > [GblId, > Arity=1, > Str=DmdType L, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [0] 40 0}] > Test.test = > \ (m_aPx > :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int) -> > case Test.test1 m_aPx of _ { > Data.Maybe.Nothing -> Repro.!1 @ GHC.Types.Int; > Data.Maybe.Just y_atN -> y_atN > } > }}} > > **EDIT** > > There is yet another funny issue here. If I try to compile the modules > like so: `time ghc -O2 -fenable-rewrite-rules -ddump-spec B.hs` GHC > prints the following lines and hangs forever: > > {{{ > > [1 of 2] Compiling A ( A.hs, A.o ) > > ==================== Specialise ==================== > Result size of Specialise > = {terms: 60, types: 80, coercions: 3,048,032} > > Rec { > $dShow_a20B :: Show String > [LclId, > Str=DmdType, > Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, > Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] > $dShow_a20B = GHC.Show.$fShow[]_$s$fShow[]1 > > $dPerfC1_a1Rk :: PerfC1 Int > [LclId, > Arity=1, > Str=DmdType, > Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] > > }}} New description: If a function marked as `INLINABLE` is called indirectly through a simple wrapper defined in a different module, specialization never happens (i.e. none of the dictionaries are removed.) Here's an example where it fails. First, the simple wrapper module: {{{ module Repro where import Data.Hashable import Data.HashMap.Strict as M infixl 9 ! (!) :: (Eq a, Hashable a) => M.HashMap a b -> a -> b m ! x = case M.lookup x m of -- lookup is INLINABLE Just y -> y Nothing -> error "Repro.!" }}} and then the call site: {{{ module Test (test) where import Data.HashMap.Strict as M import Repro test :: M.HashMap Int Int -> Int test m = m ! 42 }}} To compile the code you need to `cabal install unordered-containers`. The relevant function (which is not getting specialized) from unordered- containers is: {{{ lookup :: (Eq k, Hashable k) => k -> HashMap k v -> Maybe v lookup k0 = go h0 k0 0 where h0 = hash k0 go !_ !_ !_ Empty = Nothing go h k _ (Leaf hx (L kx x)) | h == hx && k == kx = Just x | otherwise = Nothing go h k s (BitmapIndexed b v) | b .&. m == 0 = Nothing | otherwise = go h k (s+bitsPerSubkey) (A.index v (sparseIndex b m)) where m = mask h s go h k s (Full v) = go h k (s+bitsPerSubkey) (A.index v (index h s)) go h k _ (Collision hx v) | h == hx = lookupInArray k v | otherwise = Nothing #if __GLASGOW_HASKELL__ >= 700 {-# INLINABLE lookup #-} #endif }}} If `test` calls `lookup` directly, without using the `(!)` wrapper, things get specialized. Manually marking `(!)` as `INLINABLE` works, but users shouldn't have to do that. The core for `Repro` and `Test` is: {{{ $ ghc -O2 Test.hs -fforce-recomp -ddump-simpl [1 of 2] Compiling Repro ( Repro.hs, Repro.o ) ==================== Tidy Core ==================== Result size = 28 lvl_rNZ :: [GHC.Types.Char] [GblId] lvl_rNZ = GHC.CString.unpackCString# "Repro.!" Repro.!1 :: forall b_aBU. b_aBU [GblId, Str=DmdType b] Repro.!1 = \ (@ b_aBU) -> GHC.Err.error @ b_aBU lvl_rNZ Repro.! :: forall a_atJ b_atK. (GHC.Classes.Eq a_atJ, Data.Hashable.Hashable a_atJ) => Data.HashMap.Base.HashMap a_atJ b_atK -> a_atJ -> b_atK [GblId, Arity=4, Str=DmdType LLLL, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=4, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [0 0 0 0] 70 0}] Repro.! = \ (@ a_aBT) (@ b_aBU) ($dEq_aBV :: GHC.Classes.Eq a_aBT) ($dHashable_aBW :: Data.Hashable.Hashable a_aBT) (m_atL :: Data.HashMap.Base.HashMap a_aBT b_aBU) (x_atM :: a_aBT) -> case Data.HashMap.Base.lookup @ a_aBT @ b_aBU $dEq_aBV $dHashable_aBW x_atM m_atL of _ { Data.Maybe.Nothing -> Repro.!1 @ b_aBU; Data.Maybe.Just y_atN -> y_atN } [2 of 2] Compiling Test ( Test.hs, Test.o ) ==================== Tidy Core ==================== Result size = 20 Test.test2 :: GHC.Types.Int [GblId, Caf=NoCafRefs, Str=DmdType m, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [] 10 110}] Test.test2 = GHC.Types.I# 42 Test.test1 :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int -> Data.Maybe.Maybe GHC.Types.Int [GblId, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, ConLike=False, Cheap=False, Expandable=False, Guidance=IF_ARGS [] 40 0}] Test.test1 = Data.HashMap.Base.lookup @ GHC.Types.Int @ GHC.Types.Int GHC.Classes.$fEqInt Data.Hashable.$fHashableInt Test.test2 Test.test :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int -> GHC.Types.Int [GblId, Arity=1, Str=DmdType L, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [0] 40 0}] Test.test = \ (m_aPx :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int) -> case Test.test1 m_aPx of _ { Data.Maybe.Nothing -> Repro.!1 @ GHC.Types.Int; Data.Maybe.Just y_atN -> y_atN } }}} -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5928#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper
by GHC 17 Jan '16

17 Jan '16

#5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: | 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: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > If a function marked as `INLINABLE` is called indirectly through a simple > wrapper defined in a different module, specialization never happens (i.e. > none of the dictionaries are removed.) > > Here's an example where it fails. First, the simple wrapper module: > > {{{ > module Repro where > > import Data.Hashable > import Data.HashMap.Strict as M > > infixl 9 ! > (!) :: (Eq a, Hashable a) => M.HashMap a b -> a -> b > m ! x = case M.lookup x m of -- lookup is INLINABLE > Just y -> y > Nothing -> error "Repro.!" > }}} > > and then the call site: > > {{{ > module Test (test) where > > import Data.HashMap.Strict as M > > import Repro > > test :: M.HashMap Int Int -> Int > test m = m ! 42 > }}} > > To compile the code you need to `cabal install unordered-containers`. The > relevant function (which is not getting specialized) from unordered- > containers is: > > {{{ > lookup :: (Eq k, Hashable k) => k -> HashMap k v -> Maybe v > lookup k0 = go h0 k0 0 > where > h0 = hash k0 > go !_ !_ !_ Empty = Nothing > go h k _ (Leaf hx (L kx x)) > | h == hx && k == kx = Just x > | otherwise = Nothing > go h k s (BitmapIndexed b v) > | b .&. m == 0 = Nothing > | otherwise = go h k (s+bitsPerSubkey) (A.index v (sparseIndex > b m)) > where m = mask h s > go h k s (Full v) = go h k (s+bitsPerSubkey) (A.index v (index h s)) > go h k _ (Collision hx v) > | h == hx = lookupInArray k v > | otherwise = Nothing > #if __GLASGOW_HASKELL__ >= 700 > {-# INLINABLE lookup #-} > #endif > }}} > > If `test` calls `lookup` directly, without using the `(!)` wrapper, > things get specialized. Manually marking `(!)` as `INLINABLE` works, but > users shouldn't have to do that. > > The core for `Repro` and `Test` is: > > {{{ > $ ghc -O2 Test.hs -fforce-recomp -ddump-simpl > [1 of 2] Compiling Repro ( Repro.hs, Repro.o ) > > ==================== Tidy Core ==================== > Result size = 28 > > lvl_rNZ :: [GHC.Types.Char] > [GblId] > lvl_rNZ = GHC.CString.unpackCString# "Repro.!" > > Repro.!1 :: forall b_aBU. b_aBU > [GblId, Str=DmdType b] > Repro.!1 = \ (@ b_aBU) -> GHC.Err.error @ b_aBU lvl_rNZ > > Repro.! > :: forall a_atJ b_atK. > (GHC.Classes.Eq a_atJ, Data.Hashable.Hashable a_atJ) => > Data.HashMap.Base.HashMap a_atJ b_atK -> a_atJ -> b_atK > [GblId, > Arity=4, > Str=DmdType LLLL, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=4, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [0 0 0 0] 70 0}] > Repro.! = > \ (@ a_aBT) > (@ b_aBU) > ($dEq_aBV :: GHC.Classes.Eq a_aBT) > ($dHashable_aBW :: Data.Hashable.Hashable a_aBT) > (m_atL :: Data.HashMap.Base.HashMap a_aBT b_aBU) > (x_atM :: a_aBT) -> > case Data.HashMap.Base.lookup > @ a_aBT @ b_aBU $dEq_aBV $dHashable_aBW x_atM m_atL > of _ { > Data.Maybe.Nothing -> Repro.!1 @ b_aBU; > Data.Maybe.Just y_atN -> y_atN > } > > > [2 of 2] Compiling Test ( Test.hs, Test.o ) > > ==================== Tidy Core ==================== > Result size = 20 > > Test.test2 :: GHC.Types.Int > [GblId, > Caf=NoCafRefs, > Str=DmdType m, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [] 10 110}] > Test.test2 = GHC.Types.I# 42 > > Test.test1 > :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int > -> Data.Maybe.Maybe GHC.Types.Int > [GblId, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, > ConLike=False, Cheap=False, Expandable=False, > Guidance=IF_ARGS [] 40 0}] > Test.test1 = > Data.HashMap.Base.lookup > @ GHC.Types.Int > @ GHC.Types.Int > GHC.Classes.$fEqInt > Data.Hashable.$fHashableInt > Test.test2 > > Test.test > :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int > -> GHC.Types.Int > [GblId, > Arity=1, > Str=DmdType L, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [0] 40 0}] > Test.test = > \ (m_aPx > :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int) -> > case Test.test1 m_aPx of _ { > Data.Maybe.Nothing -> Repro.!1 @ GHC.Types.Int; > Data.Maybe.Just y_atN -> y_atN > } > }}} New description: If a function marked as `INLINABLE` is called indirectly through a simple wrapper defined in a different module, specialization never happens (i.e. none of the dictionaries are removed.) Here's an example where it fails. First, the simple wrapper module: {{{ module Repro where import Data.Hashable import Data.HashMap.Strict as M infixl 9 ! (!) :: (Eq a, Hashable a) => M.HashMap a b -> a -> b m ! x = case M.lookup x m of -- lookup is INLINABLE Just y -> y Nothing -> error "Repro.!" }}} and then the call site: {{{ module Test (test) where import Data.HashMap.Strict as M import Repro test :: M.HashMap Int Int -> Int test m = m ! 42 }}} To compile the code you need to `cabal install unordered-containers`. The relevant function (which is not getting specialized) from unordered- containers is: {{{ lookup :: (Eq k, Hashable k) => k -> HashMap k v -> Maybe v lookup k0 = go h0 k0 0 where h0 = hash k0 go !_ !_ !_ Empty = Nothing go h k _ (Leaf hx (L kx x)) | h == hx && k == kx = Just x | otherwise = Nothing go h k s (BitmapIndexed b v) | b .&. m == 0 = Nothing | otherwise = go h k (s+bitsPerSubkey) (A.index v (sparseIndex b m)) where m = mask h s go h k s (Full v) = go h k (s+bitsPerSubkey) (A.index v (index h s)) go h k _ (Collision hx v) | h == hx = lookupInArray k v | otherwise = Nothing #if __GLASGOW_HASKELL__ >= 700 {-# INLINABLE lookup #-} #endif }}} If `test` calls `lookup` directly, without using the `(!)` wrapper, things get specialized. Manually marking `(!)` as `INLINABLE` works, but users shouldn't have to do that. The core for `Repro` and `Test` is: {{{ $ ghc -O2 Test.hs -fforce-recomp -ddump-simpl [1 of 2] Compiling Repro ( Repro.hs, Repro.o ) ==================== Tidy Core ==================== Result size = 28 lvl_rNZ :: [GHC.Types.Char] [GblId] lvl_rNZ = GHC.CString.unpackCString# "Repro.!" Repro.!1 :: forall b_aBU. b_aBU [GblId, Str=DmdType b] Repro.!1 = \ (@ b_aBU) -> GHC.Err.error @ b_aBU lvl_rNZ Repro.! :: forall a_atJ b_atK. (GHC.Classes.Eq a_atJ, Data.Hashable.Hashable a_atJ) => Data.HashMap.Base.HashMap a_atJ b_atK -> a_atJ -> b_atK [GblId, Arity=4, Str=DmdType LLLL, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=4, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [0 0 0 0] 70 0}] Repro.! = \ (@ a_aBT) (@ b_aBU) ($dEq_aBV :: GHC.Classes.Eq a_aBT) ($dHashable_aBW :: Data.Hashable.Hashable a_aBT) (m_atL :: Data.HashMap.Base.HashMap a_aBT b_aBU) (x_atM :: a_aBT) -> case Data.HashMap.Base.lookup @ a_aBT @ b_aBU $dEq_aBV $dHashable_aBW x_atM m_atL of _ { Data.Maybe.Nothing -> Repro.!1 @ b_aBU; Data.Maybe.Just y_atN -> y_atN } [2 of 2] Compiling Test ( Test.hs, Test.o ) ==================== Tidy Core ==================== Result size = 20 Test.test2 :: GHC.Types.Int [GblId, Caf=NoCafRefs, Str=DmdType m, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [] 10 110}] Test.test2 = GHC.Types.I# 42 Test.test1 :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int -> Data.Maybe.Maybe GHC.Types.Int [GblId, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, ConLike=False, Cheap=False, Expandable=False, Guidance=IF_ARGS [] 40 0}] Test.test1 = Data.HashMap.Base.lookup @ GHC.Types.Int @ GHC.Types.Int GHC.Classes.$fEqInt Data.Hashable.$fHashableInt Test.test2 Test.test :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int -> GHC.Types.Int [GblId, Arity=1, Str=DmdType L, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [0] 40 0}] Test.test = \ (m_aPx :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int) -> case Test.test1 m_aPx of _ { Data.Maybe.Nothing -> Repro.!1 @ GHC.Types.Int; Data.Maybe.Just y_atN -> y_atN } }}} **EDIT** There is yet another funny issue here. If I try to compile the modules like so: `time ghc -O2 -fenable-rewrite-rules -ddump-spec B.hs` GHC prints the following lines and hangs forever: {{{ [1 of 2] Compiling A ( A.hs, A.o ) ==================== Specialise ==================== Result size of Specialise = {terms: 60, types: 80, coercions: 3,048,032} Rec { $dShow_a20B :: Show String [LclId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] $dShow_a20B = GHC.Show.$fShow[]_$s$fShow[]1 $dPerfC1_a1Rk :: PerfC1 Int [LclId, Arity=1, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] }}} -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5928#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10921: weird "optimisation levels" in man page
by GHC 17 Jan '16

17 Jan '16

#10921: weird "optimisation levels" in man page -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Keywords: manpage, | Operating System: Unknown/Multiple newcomer | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Man page shows this: {{{ Optimisation levels -O0 -O -O or -O1 -O0 -O2 -O0 -Odph }}} This looks very weird: - Why -O and -O0 listed twice? - That `or` looks weird, how do I read that? Apparently the man page is auto-generated from the user manual(thanks @int-e), and while doing that "reverse" column is also included. We should probably either ignore "reverse" column while parsing the user manual parts or somehow re-format generated man page lines. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10921> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8114: GHC panic when building `thyme`
by GHC 16 Jan '16

16 Jan '16

#8114: GHC panic when building `thyme` -----------------------------------+--------------------------------------- Reporter: Ptharien's | Owner: Flame | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: MacOS X Keywords: | Type of failure: Compile-time crash Architecture: x86_64 (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- While attempting to build `thyme` from Hackage with core, stg, and cmm linting and -O2 enabled, GHC crashed with an internal panic. See attached terminal log. {{{ rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ cabal --version cabal-install version 1.16.0.2 using version 1.16.0 of the Cabal library rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ which ghc /usr/local/bin/ghc rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ which cabal /Users/Alexander/Library/Haskell/bin/cabal }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11355: TypeApplications + RankNTypes permits "impredicativity"
by GHC 16 Jan '16

16 Jan '16

#11355: TypeApplications + RankNTypes permits "impredicativity" -------------------------------------+------------------------------------- Reporter: adamgundry | 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: -------------------------------------+------------------------------------- I was slightly surprised to discover that the combination of `TypeApplications` and `RankNTypes` allows impredicative instantiations, for example: {{{#!hs map @(forall a . a) :: ((forall a. a) -> b) -> [forall a. a] -> [b] }}} Is this desirable, or should it require `ImpredicativeTypes`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11355> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10872: More informative assertion for non-unique TH names
by GHC 16 Jan '16

16 Jan '16

#10872: More informative assertion for non-unique TH names -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: low | 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 Revisions: | -------------------------------------+------------------------------------- Let's say that by accident I have duplicated uniques of Template Haskell built-in identifiers defined in `THNames` module: {{{#!hs returnQIdKey = mkPreludeMiscIdUnique 200 bindQIdKey = mkPreludeMiscIdUnique 200 }}} If I have a debugging build (`-DDEBUG`) and start a GHCi session it crashes immediately with a very uninformative error message: {{{ GHCi, version 7.11.20150903: http://www.haskell.org/ghc/ :? for help <interactive>:1:1: error: Bad interface file: /dane/projekty/ghc/build/libraries/base/dist- install/build/Prelude.hi ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150903 for x86_64-unknown-linux): ASSERT failed! <<details unavailable>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I have no idea where this assertion comes from as it gives absolutely no clue as to what caused the problem. During ICFP this costed me and Richard a total of around 6 man-hours. We should replace that assertion with something more meaningful. One thing we could do is add an assertion to the definition of `THNames.templateHaskellNames` that makes sure that `length templateHaskellNames == length (nub templateHaskellNames)`. That by itself is very simple but the problem is that the uninformative assertion given above still kicks in first. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10872> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11311: segmentation fault/panic with -XTypeInType and functions of type * -> *
by GHC 16 Jan '16

16 Jan '16

#11311: segmentation fault/panic with -XTypeInType and functions of type * -> * -------------------------------------+------------------------------------- Reporter: rwbarton | 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: -------------------------------------+------------------------------------- Since `* :: *`, I can specialize a function of type `a -> a` to type `* -> *`. This seems like potentially not a great idea, and GHCi agrees: {{{ rwbarton@morphism:/tmp$ ~/ghc-newest/inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151228: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeInType Prelude> import Data.Kind Prelude Data.Kind> :t id :: * -> * id :: * -> * :: * -> * Prelude Data.Kind> (id :: * -> *) undefined `seq` () Segmentation fault }}} Also, when compiling a module containing the above expression, I get a panic while producing Cmm: {{{ rwbarton@morphism:/tmp$ ~/ghc-newest/inplace/bin/ghc-stage2 t [1 of 1] Compiling Main ( t.hs, t.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151228 for x86_64-unknown-linux): idToReg sat_sKV }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11311> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11254: GHC panic
by GHC 16 Jan '16

16 Jan '16

#11254: GHC panic ----------------------------------------+--------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- I like to mix features to make code fail, code inspired by [https://phabricator.haskell.org/diffusion/GHC/browse/master/testsuite/tests /indexed-types/should_compile/T10318.hs$1 T10318]: {{{#!hs -- /tmp/panic.hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeSynonymInstances #-} {-# LANGUAGE UndecidableSuperClasses #-} class (Frac (Frac a) ~ Frac a, Fractional (Frac a), ID (Frac a)) => ID a where type Frac a embed :: a -> Frac a instance ID Rational where type Frac Rational = Int embed :: Rational -> Rational embed = undefined }}} When running it with `defer-type-errors` it causes GHC to panic: {{{#!hs % ghci -fdefer-type-errors -ignore-dot-ghci panic.hs &> panic.log }}} actual error included in panic.log. GHC asks me to report this as a bug and I do as I'm told. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11254> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11404: The type variable used in a kind is still used
by GHC 16 Jan '16

16 Jan '16

#11404: The type variable used in a kind is still used -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From Phab:D1739. When you say {{{ undefined :: forall (v :: Levity) (a :: TYPE v). (?callStack :: CallStack) => a }}} you get a warning that `v` is unused. I will fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11404> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11405: Incorrect failure of type-level skolem escape check
by GHC 16 Jan '16

16 Jan '16

#11405: Incorrect failure of type-level skolem escape check -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From Phab:D1739. When you say {{{ undefined :: forall (v :: Levity). forall (a :: TYPE v). (?callStack :: CallStack) => a }}} you get a skolem escape failure because GHC things that the kind of `(?callStack :: CallStack) => a` is `TYPE v`. It should be `*`. I will fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11405> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12