November 2015 - ghc-tickets

[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] #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] #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] #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

[GHC] #8308: Resurrect ticky code for counting constructor arity
by GHC 12 Jul '16

12 Jul '16

#8308: Resurrect ticky code for counting constructor arity ----------------------------------------------+---------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: ----------------------------------------------+---------------------------- There is a dead piece of ticky profiling code that computes histograms of data constructor arities (including tuples) and size of vector returns. The function responsible is `bumpHistogram` in [[GhcFile(compiler/codeGen/StgCmmTicky.hs)]], which masks the commented out function `bumpHistogramE`. We can improve ticky profiling by resurrecting this dead code. There are following things that need to be done: 1. Replace current no-op `bumpHistogram` with `bumpHistogramE`. Note that current implementation of `bumpHistogramE` computes constructor arity at runtime. This is unnecessary because we know arity at compile time so we can avoid runtime check by doing sth like this: {{{ bumpHistogram lbl n = do let offset = n `min` 8 emit (addToMem cLong (cmmIndexExpr cLongWidth (CmmLit (CmmLabel (mkRtsDataLabel lbl))) (CmmReg (CmmInt (fromIntegral offset) cLongWidth))) 1) }}} Note that `mkRtsDataLabel` function does not exist anymore but we should be able to replace that call with `mkCmmDataLabel rtsPackageId lbl` (speculation). 2. We need to declare arrays that will store histogram values. Declarations of variables used for storing ticky statistics are in [[GhcFile(includes/stg/Ticky.h)]]. We also need to initialize the declared array to contain only zeros. 3. Having declared the arrays we need to fix printing of computed arities. This is done in [[GhcFile(rts/Ticky.c)]]. Note that there is a lot of code that is commented out (`/* krc: comment out some of this stuff temporarily */`) or disabled with `#if FALSE` pragma. We need to resurect *some* of it. There is a `PR_HST` macro for printing one histogram entry. This seems bad. We should probably rework the part of code responsible for printing out results of historgams. 4. Current code counts arities from 0 to 8. Everything above 8 is put into the same bin as 8. This magical 8 is spread all over the code. We should declare a constant that is visible both in Haskell sources (see `bumpHistogram` in 1.) and RTS files and have all code behave properly depending on that constant - we should have loops instead of statically printing 9 elements of histogram array. 5. Some ticky functions that count arity histograms are not used. For example `tickyReturnNewCon` should probably be called by `cgConApp` like this: {{{ ; emit =<< fcode_init ; tickyReturnNewCon ; emitReturn [idInfoToAmode idinfo] } }}} The above is a an outline, which should be fairly accurate, but unexpected things may show up along the way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8308> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #10886: Remove the magic from `Any`
by GHC 11 Jul '16

11 Jul '16

#10886: Remove the magic from `Any` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The `Any` type used to be very highly magical: a poly-kinded type in a mono-kinded world. Then it became only normally magical: a datatype with a return kind of `k` (instead of `*`). Then it became only a bit magical: a closed type family with no equations. Now that we have non-magical empty closed type families, I believe that we can remove the last bit of magic and just define {{{ type family Any :: k where { } }}} somewhere (`GHC.Types`?), wire it in (like, e.g., `Bool`), and be done with it. Objections? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10886> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10311: package name returned from tyConPackage is garbled
by GHC 08 Jul '16

08 Jul '16

#10311: package name returned from tyConPackage is garbled -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I am using tyConPackage (etc.) to programmatically generate links to haddock documentation (e.g., from a typed edit widget). This is now broken: {{{ import Data.Map import Data.Typeable tyConPackage $ typeRepTyCon $ typeOf $ fromList [(1,2)] in ghc-7.8.4: "containers-0.5.5.1" in ghc-7.10.1: "conta_47ajk3tbda43DFWyeF3oHQ" }}} and I don't see how to get the actual package name. Cf. http://stackoverflow.com/questions/29638177/tyconpackage-changed-from- ghc-7-8-to-ghc-7-10 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10311> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9625: ghc: panic using --enable-executable-dynamic
by GHC 08 Jul '16

08 Jul '16

#9625: ghc: panic using --enable-executable-dynamic -------------------------------------+------------------------------------- Reporter: CoreyOConnor | 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: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- (from: https://github.com/haskell/cabal/issues/2039) Using --enable-executable-dynamic leads to a ghc panic. Reproduction steps: 1. clone https://github.com/coreyoconnor/executable-dynamic-issue 2. cabal configure --enable-tests --enable-executable-dynamic 3. cabal test Expected results: Test executes and passes. Actual results: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64 -unknown-linux): Don't understand library name verify-foo }}} Actual results varies based on the name of "verify-foo" test suite. Other names tried: "verifyFoo", "VerifyFoo". All of which also fail. Removing "--enable-executable-dynamic" results in a pass regardless of test suite name. Reproduced on GHC 7.8.2, GHC 7.8.3, Cabal 1.18, Cabal 1.20. Ubuntu. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9625> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9078: Segfault with makeStableName
by GHC 28 Jun '16

28 Jun '16

#9078: Segfault with makeStableName ------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Calling `makeStableName` on the same object many times causes a segfault. The following triggers this behaviour on both OSX and Linux-x86_64, provided it is compiled (it doesn't seem to occur if the call to `makeStableName` is interpreted). {{{ module Main where import Control.Monad import System.Mem.StableName main :: IO () main = replicateM_ 100000 (makeStableName foo) foo :: Int foo = 1 }}} It seems to happen largely at random. The 100000 calls to `makeStableName` in the above example essentially guarantee its occurrence, but I have observed it happen with far fewer. The reason this bug was discovered is it is causing frequent failures in Accelerate on 7.8.2. See [https://github.com/AccelerateHS/accelerate/issues/162] In that case it seems to be causing more `strange closure type` errors than segfaults, but I assume it is the same root cause. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9078> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24