April 2016 - ghc-tickets

[GHC] #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200
by GHC 03 Aug '16

03 Aug '16

#11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: 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: 10527 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is perhaps the same bug as #10527 but I'm not sure, as it goes away with a modest bump to `-fsimpl-tick-factor`. I'm developing a library and am seeing this when I go to compile a small hello-world executable. {{{ <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $fMonadIdentity_$c>>= To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 6642 }}} If I remove the `INLINE` from the exported functions it goes away, but also makes the code much slower (for some reason the way I use the function in my benchmark suite doesn't exhibit the error). It also compiles with `-fsimpl-tick-factor=200`. Previously on 7.10.1 I got the same error in a different part of my code (the test suite) which went away when I moved to 7.10.3. If it's helpful I can upload the state of the repo, but it's not a small test case. Even if this is a duplicate, I'd love some guidance on this: Is this actually a ghc bug, or is it my fault that I've got too much inlining in my code (I've never seen anything like this before, and pretty much mark everything INLINE)? Should I pass this off to my users and should it be their responsibility to bump `-fsimpl-tick-factor` to work around regressions in their GHC? If I want to try to work around this in my library, what strategies could I employ (besides disabling inlining of exported functions)? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11263> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8473: Generate table of cost-centre numbers with source locations
by GHC 01 Aug '16

01 Aug '16

#8473: Generate table of cost-centre numbers with source locations ------------------------------------+------------------------------------- Reporter: lars_e_krueger | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | 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: 7105 | ------------------------------------+------------------------------------- .prof files contain a cost centre number, which I assume is cc_key from CostCentre.lhs. It would be immensely helpful if the compiler creates a simpe table. This way, one could look up the number in .prof, check the table and the exact source location. It would also help with #7105, I think. Suggestion for the format: {{{ no. file begin end 1 main.hs 127:7 128:14 }}} Meaning: Cost centre 1 is in file main.hs, begins at line 127, character 7 and ends at line 128, character 14. If somebody points me in the right direction, and the whole thing is not too complicated, I can try my hand at implementing it myself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8473> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10957: getExecutablePath adds " (deleted)" suffix if executable was deleted under linux
by GHC 22 Jul '16

22 Jul '16

#10957: getExecutablePath adds " (deleted)" suffix if executable was deleted under linux -------------------------------------+------------------------------------- Reporter: aslpavel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.2 Libraries | Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If we remove current executable or update it with a new one, getExecutablePath returns path with added " (deleted)" suffix. I think it is incorrect behavior , for example if you updated binary and want to exec a new one, the obvious way to go is to call getExecutablePath and use it. Moreover it is inconsistent between platforms. Problem stems from the fact the getExecutablePath is implemented as readlink on /proc/self/exe and it contains gibberish once file has been deleted. Example: {{{#!hs module Main (main) where import System.Environment (getExecutablePath) import System.Directory (removeFile) main :: IO () main = do before <- getExecutablePath putStrLn $ "Before: " ++ before removeFile before after <- getExecutablePath putStrLn $ "After: " ++ after }}} Output: {{{ $ ./getExecutablePath Before: /mnt/data/Maggot/getExecutablePath After: /mnt/data/Maggot/getExecutablePath (deleted) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10957> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11357: Regression when deriving Generic1 on poly-kinded data family
by GHC 20 Jul '16

20 Jul '16

#11357: Regression when deriving Generic1 on poly-kinded data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 (CodeGen) | Keywords: Generics, | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On GHC 7.10.3, the following code compiles: {{{#!hs {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module ProxyFam where import GHC.Generics (Generic1) data family ProxyFam (a :: k) data instance ProxyFam (a :: k) = ProxyCon deriving Generic1 }}} But on GHC 8.1, it fails: {{{ $ /opt/ghc/head/bin/ghc ProxyFam.hs [1 of 1] Compiling ProxyFam ( ProxyFam.hs, ProxyFam.o ) ProxyFam.hs:10:53: error: • Can't make a derived instance of ‘Generic1 ProxyFam’: ProxyFam must not be instantiated; try deriving `ProxyFam k a' instead • In the data instance declaration for ‘ProxyFam’ }}} I'm not sure what exactly is going on here, but I have a hunch. The `Generic1` typeclass is of kind `* -> *`, which means that in a `Generic1 ProxyFam` instance, the kind of `a` is instantiated to `*`. Curiously, though, the same error does ''not'' appear when `deriving Generic` for a normal datatype (e.g., `data ProxyFam (a :: k) = ProxyCon deriving Generic1`). Richard, I'm stuck as to how to fix this. I suspect this was triggered by `-XTypeInType`-related changes, specifically, [http://git.haskell.org/ghc.git/blobdiff/6e56ac58a6905197412d58e32792a04a63b… this change]: {{{#!diff diff --git a/compiler/typecheck/TcGenGenerics.hs b/compiler/typecheck/TcGenGenerics.hs index 2c5b80e..fb18517 100644 (file) --- a/compiler/typecheck/TcGenGenerics.hs +++ b/compiler/typecheck/TcGenGenerics.hs @@ -147,7 +146,7 @@ canDoGenerics tc tc_args -- -- Data family indices can be instantiated; the `tc_args` here are -- the representation tycon args - (if (all isTyVarTy (filterOut isKind tc_args)) + (if (all isTyVarTy (filterOutInvisibleTypes tc tc_args)) then IsValid else NotValid (tc_name <+> text "must not be instantiated;" <+> text "try deriving `" <> tc_name <+> tc_tys <> }}} What exactly does `filterOutInvisibleTypes` do? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11357> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #11094: Cost-center heap profiler should be able to emit samples to eventlog
by GHC 20 Jul '16

20 Jul '16

#11094: Cost-center heap profiler should be able to emit samples to eventlog -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Often when looking at heap profiles I find myself wishing that I had better tools for aligning the heap behavior to various events in the lifetime of my program. The eventlog provides a nice facility for marking these events, why not record heap profile samples in the eventlog as well? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11094> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11348: Local open type families instances ignored during type checking
by GHC 20 Jul '16

20 Jul '16

#11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeInType #-} import Data.Kind import Data.Proxy type family TrivialFamily t :: Type type instance TrivialFamily (t :: Type) = Bool data R where R :: Proxy Bool -> R type ProblemType t = 'R ('Proxy :: Proxy (TrivialFamily t)) }}} Compiling this program as-is, GHC rejects it! {{{#!sh error: • Expected kind ‘Proxy Bool’, but ‘'Proxy’ has kind ‘Proxy (TrivialFamily t)’ • In the first argument of ‘R’, namely ‘(Proxy :: Proxy (TrivialFamily t))’ In the type ‘R (Proxy :: Proxy (TrivialFamily t))’ In the type declaration for ‘ProblemType’ }}} But if we move `TrivialFamily` to another module and import it, GHC discovers that `TrivialFamily t = Bool` and the program is accepted. When compiling the rejected program (with the local family instance) I observe that the instance environments given by `FamInst.tcGetFamInstEnvs` contain no instances! The renamer processes the local instance, but no `FamInst` is created for it, and nothing enters the `TcGblEnv`'s family instance record. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11348> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #11717: Way to dump cmm only once
by GHC 18 Jul '16

18 Jul '16

#11717: Way to dump cmm only once -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (CodeGen) | Keywords: newcomer | 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 current way to dump Cmm output is `-ddump-cmm`, but that dumps Cmm repeatedly, of every stage, similar to `-ddump-verbose-core2core`. This is often confusing. I propose that `-ddump-cmm` dumps only the initial Cmm code, that the flag `-ddump-simpl-cmm` dumps the final Cmm code, and that `-ddump-verbose-cmm` dumps every stage. Shoudn’t be hard to do for a newcomer. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11717> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8732: Global big object heap allocator lock causes contention
by GHC 17 Jul '16

17 Jul '16

#8732: Global big object heap allocator lock causes contention ------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | 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: | ------------------------------------+------------------------------------- The lock allocate() takes when allocating big objects hurts scalability of I/O bound application. Network.Socket.ByteString.recv is typically called with a buffer size of 4096, which causes a ByteString of that size to be allocate. The size of this ByteString causes it to be allocated from the big object space, which causes contention of the global lock that guards that space. See http://www.yesodweb.com/blog/2014/02/new-warp for a real world example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8732> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #11835: ApplicativeDo failed to desugar last line with pure $ <expr>
by GHC 12 Jul '16

12 Jul '16

#11835: ApplicativeDo failed to desugar last line with pure $ <expr> -------------------------------------+------------------------------------- Reporter: Cosmia | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: ApplicativeDo | Operating System: MacOS X Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #11607 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE ApplicativeDo #-} f m = do x <- m 1 y <- m 2 return $ x + y }}} f should have type (Applicative f, Num a, Num b) => (a -> f b) -> f b but ghc considers f a monad maybe similar with #11607 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11835> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10647: Notice about lack of SIMD support.
by GHC 12 Jul '16

12 Jul '16

#10647: Notice about lack of SIMD support. -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- In some cases, when SIMD primitives are used without the `-fllvm` flag, instead of giving the friendly `SIMD vector instructions require the LLVM back-end.`, GHC crashes with varying messages. The simplest example is {{{#!hs {-# LANGUAGE MagicHash #-} module Foo where import GHC.Prim data V = V Int8X16# }}} In 7.8.4 this crashes with {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Size.intSize W128 }}} According to osa1, in HEAD this still crashes, but with {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150717 for x86_64-unknown-linux): Format.intFormat W128 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7