- ghc-tickets - Haskell.org

[GHC] #13035: GHC enters a loop when partial type signatures and advanced type level code mix
by GHC 09 Jan '17

09 Jan '17

#13035: GHC enters a loop when partial type signatures and advanced type level code mix -------------------------------------+------------------------------------- Reporter: xcmw | Owner: 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: -------------------------------------+------------------------------------- GHC loops when compiling this code. Replacing the _ with the actual type fixes the error. {{{#!hs {-# LANGUAGE PolyKinds, DataKinds, TypeOperators, TypeFamilies, TemplateHaskell, GADTs, PartialTypeSignatures #-} import Data.Vinyl import Data.Singletons.TH newtype MyAttr a b = MyAttr { _unMyAttr :: MyFun (a b) } type MyRec a b = Rec (MyAttr a) b type family MyFun (a :: k1) :: k2 data GY (a :: k1) (b :: k2) (c :: k1 -> k3) (d :: k1) data GNone (a :: k1) type family GYTF a where GYTF (GY a b _ a) = b GYTF (GY _ _ c d) = MyFun (c d) type instance MyFun (GY a b c d) = GYTF (GY a b c d) type family GNoneTF (a :: k1) :: k2 where type instance MyFun (GNone a) = GNoneTF a type (a :: k1) =: (b :: k2) = a `GY` b type (a :: j1 -> j2) $ (b :: j1) = a b infixr 0 $ infixr 9 =: data FConst (a :: *) (b :: Fields) data FApply (a :: * -> * -> *) b c (d :: Fields) data FMap (a :: * -> *) b (d :: Fields) type instance MyFun (FConst a b) = a type instance MyFun (FApply b c d a) = b (MyFun (c a)) (MyFun (d a)) type instance MyFun (FMap b c a) = b (MyFun (c a)) data Fields = Name | Author | Image | Description | Ingredients | Instructions | CookTime | PrepTime | TotalTime | Yield | Nutrition | Tags | Url | Section | Items | Subsections | Calories | Carbohydrates | Cholesterol | Fat | Fiber | Protien | SaturatedFat | Sodium | Sugar | TransFat | UnsaturatedFat | ServingSize genSingletons [ ''Fields ] (=::) :: sing f -> MyFun (a f) -> MyAttr a f _ =:: x = MyAttr x type NutritionT = Calories =: Maybe Int $ Carbohydrates =: Maybe Int $ Cholesterol =: Maybe Int $ Fat =: Maybe Int $ Fiber =: Maybe Int $ Protien =: Maybe Int $ SaturatedFat =: Maybe Int $ Sodium =: Maybe Int $ Sugar =: Maybe Int $ TransFat =: Maybe Int $ UnsaturatedFat =: Maybe Int $ ServingSize =: String $ GNone type NutritionRec = MyRec NutritionT ['Calories, 'Carbohydrates, 'Cholesterol, 'Fat, 'Fiber, 'Protien, 'SaturatedFat, 'Sodium, 'Sugar, 'TransFat, 'UnsaturatedFat, 'ServingSize] type RecipeT = Name =: String $ Author =: String $ Image =: String $ Description =: String $ CookTime =: Maybe Int $ PrepTime =: Maybe Int $ TotalTime =: Maybe Int $ Yield =: String $ Nutrition =: NutritionRec $ Tags =: [String] $ Url =: String $ GNone type RecipeFormatter = FApply (->) (FConst [String]) (FMap IO RecipeT) g :: MyRec RecipeFormatter _ --'[ 'Author ] Uncomment to prevent loop g = SAuthor =:: (\a -> return "Hi") :& RNil main = putStrLn "Hi" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13035> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13078: Panic from ghc-stage1 when building HEAD with profiling
by GHC 09 Jan '17

09 Jan '17

#13078: Panic from ghc-stage1 when building HEAD with profiling -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- When building 3a18baff06abc193569b1b76358da26375b3c8d6 with profiling, GHC emits this error: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20170106 for x86_64-unknown-linux): kindPrimRep.go k0 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:369:9 in ghc:RepType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I have attached my `build.mk` file. It may be wrong, but I don't think it includes anything that should break GHC. Even if it did, I should get some sort of error message, not a panic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13078> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13089: GHC panic
by GHC 09 Jan '17

09 Jan '17

#13089: GHC panic -------------------------------------+------------------------------------- Reporter: cbaatz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I stumbled upon a GHC panic for some reason. Not sure how to debug this/get more details on it so attaching the error message: ``` ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): filterImports/combine (Array, Array{Array, AByteString, ACursored, ADelayed, AForeignPtr, AInterleave, ASmall, APart, AUnboxed, AUndefined, AVector, cursoredExtent, loadCursor, makeCursor, shiftCursor}, Nothing) (Array, Source{Source, Array, deepSeqArray, extent, index, linearIndex, unsafeIndex, unsafeLinearIndex}, Nothing) ``` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13089> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13050: Holes don't work infix
by GHC 09 Jan '17

09 Jan '17

#13050: Holes don't work infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- As pointed out in this [https://twitter.com/deech/status/815294260115369985 tweet], holes don't work infix {{{ #Haskell holes don't work with infixed functions, eg. _ 1 1 (Hole found: Integer -> Integer -> ...) 1 `_` 1 (parse error) 1 `_x` 1 (same) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13050> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13086: (\\) in Data.List uses foldl instead of foldl'
by GHC 08 Jan '17

08 Jan '17

#13086: (\\) in Data.List uses foldl instead of foldl' -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- The list difference operator `(\\)` is currently defined in terms of `foldl`: https://hackage.haskell.org/package/base-4.9.0.0/docs/src/Data.OldList.html…. Should it be using `foldl'` instead? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13086> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12511: template-haskell's Language.Haskell.Syntax module should be Trustworthy
by GHC 08 Jan '17

08 Jan '17

#12511: template-haskell's Language.Haskell.Syntax module should be Trustworthy -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: libraries | Version: 8.0.1 (other) | 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: -------------------------------------+------------------------------------- The reason why this module isn't inferred safe is that it uses `unsafePerformIO` to create a global `IORef`. From a SafeHaskell perspective, this module isn't very useful in itself, but its unsafety prevents other modules that import it to provide class instances from being inferred as safe. A concrete example is https://hackage.haskell.org/package/exceptions-0.8.3/docs/src/Control- Monad-Catch.html#line-186 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12511> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13063: Program uses 8GB of memory
by GHC 08 Jan '17

08 Jan '17

#13063: Program uses 8GB of memory -------------------------------------+------------------------------------- Reporter: codygman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling this repo with stack build it uses 8GB of memory. Even using -O0 it runs quickly but uses 8GB of memory: https://github.com/codygman/frames-example-cdi I've attached a -ddump-simple-iterations log of this build. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13063> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13081: Code size explosion with with inlined instances for fixed point of functor
by GHC 08 Jan '17

08 Jan '17

#13081: Code size explosion with with inlined instances for fixed point of functor -------------------------------------+------------------------------------- Reporter: kja | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code is not feasible to compile due to a massive explosion in "terms" generated by the simplifier as reported by `-v` flag. {{{#!hs ---[ import Data.Functor.Fixedpoint from unification-fd ]----------------- newtype Fix f = Fix { unFix :: f (Fix f) } instance (Eq (f (Fix f))) => Eq (Fix f) where x == y = unFix x == unFix y x /= y = unFix x /= unFix y -------------------------------------------------------------------------------- data Foo' a = A | B a | C a | D a a | E a a a deriving (Eq) type Foo = Fix Foo' bar :: Foo -> Foo -> m () bar t t' = if t == t' then undefined else undefined }}} Compiling with `-v` on 8.0.2 yields: {{{ [1 of 1] Compiling Lib ( src/Lib.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.2.0/build/Lib.o ) *** Parser [Lib]: !!! Parser [Lib]: finished in 0.90 milliseconds, allocated 0.797 megabytes *** Renamer/typechecker [Lib]: !!! Renamer/typechecker [Lib]: finished in 136.61 milliseconds, allocated 57.026 megabytes *** Desugar [Lib]: Result size of Desugar (after optimization) = {terms: 257, types: 237, coercions: 24} !!! Desugar [Lib]: finished in 2.38 milliseconds, allocated 1.264 megabytes *** Simplifier [Lib]: Result size of Simplifier iteration=1 = {terms: 297, types: 305, coercions: 18} Result size of Simplifier = {terms: 294, types: 301, coercions: 18} !!! Simplifier [Lib]: finished in 3.78 milliseconds, allocated 2.165 megabytes *** Specialise [Lib]: Result size of Specialise = {terms: 294, types: 301, coercions: 18} !!! Specialise [Lib]: finished in 0.52 milliseconds, allocated 0.382 megabytes *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Lib]: Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 366, types: 418, coercions: 18} !!! Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Lib]: finished in 1.38 milliseconds, allocated 1.657 megabytes *** Simplifier [Lib]: Result size of Simplifier iteration=1 = {terms: 364, types: 362, coercions: 38} Result size of Simplifier iteration=2 = {terms: 311, types: 325, coercions: 38} Result size of Simplifier iteration=3 = {terms: 395, types: 417, coercions: 74} Result size of Simplifier iteration=4 = {terms: 395, types: 410, coercions: 74} Result size of Simplifier = {terms: 395, types: 410, coercions: 74} !!! Simplifier [Lib]: finished in 9.11 milliseconds, allocated 5.846 megabytes *** Simplifier [Lib]: Result size of Simplifier iteration=1 = {terms: 991, types: 1,022, coercions: 326} Result size of Simplifier iteration=2 = {terms: 991, types: 973, coercions: 326} Result size of Simplifier iteration=3 = {terms: 5,323, types: 5,433, coercions: 2,090} Result size of Simplifier iteration=4 = {terms: 5,323, types: 5,090, coercions: 2,090} Result size of Simplifier = {terms: 5,323, types: 5,090, coercions: 2,090} !!! Simplifier [Lib]: finished in 95.35 milliseconds, allocated 60.572 megabytes *** Simplifier [Lib]: Result size of Simplifier iteration=1 = {terms: 35,839, types: 36,118, coercions: 14,438} Result size of Simplifier iteration=2 = {terms: 35,839, types: 33,717, coercions: 14,438} Result size of Simplifier iteration=3 = {terms: 250,219, types: 250,145, coercions: 100,874} Result size of Simplifier iteration=4 = {terms: 250,219, types: 233,338, coercions: 100,874} Result size of Simplifier = {terms: 250,219, types: 233,338, coercions: 100,874} !!! Simplifier [Lib]: finished in 5567.46 milliseconds, allocated 2798.871 megabytes *** Float inwards [Lib]: Result size of Float inwards = {terms: 250,219, types: 233,338, coercions: 100,874} !!! Float inwards [Lib]: finished in 744.72 milliseconds, allocated 594.429 megabytes *** Called arity analysis [Lib]: Result size of Called arity analysis = {terms: 250,219, types: 233,338, coercions: 100,874} !!! Called arity analysis [Lib]: finished in 311.34 milliseconds, allocated 190.166 megabytes *** Simplifier [Lib]: }}} ... at which point it seems to "hang", though depending on hardware it might still succeed. It is clearly proportional in the number of constructors and occurrences of the type variable in those constructor. To aggravate the issue, simply add more of both. Any of ... * compiling with -O0 * adding a NOINLINE pragma to `(==)` in the instance for `Fix` * implementing a manual `Eq` instance for `Foo` and adding a NOINLINE pragma there ... solves the issue for me. Observed on both 8.0.1 (Windows and macOS) and 8.0.2 (macOS) Not present on 7.10.3 (Windows and macOS). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13081> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb
by GHC 07 Jan '17

07 Jan '17

#7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Profiling | Version: 7.4.2 Resolution: | Keywords: profiling osx Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by domenkozar): Reproduced on Linux using "+RTS -N -pa -hb -T -A6G -qg -RTS": cardano-node: internal error: Invalid object in processHeapClosureForDead(): 0 (GHC version 8.0.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7836#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13048: Splitter is O(n^2)
by GHC 07 Jan '17

07 Jan '17

#13048: Splitter is O(n^2) -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: split-objs | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The splitter is O(local constants * total size of code), which is O(n^2^). This can be dealt with by not looping over each local constant, and instead scraping the local constants used from the assembler code and then looking them up in the hashtable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13048> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1