- ghc-tickets - Haskell.org

Re: [GHC] #2289: Needless reboxing of values when returning from a tight loop
by GHC 07 Oct '13

07 Oct '13

#2289: Needless reboxing of values when returning from a tight loop -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: boxing, loops, Operating System: Unknown/Multiple | performance Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2387,#1600 -------------------------------------+------------------------------------- Comment (by simonpj): In fact it's orthogonal to do with loopification, which does not affect allocation. Its to do with nested CPR analysis, which I'm longing to do but keep getting diverted. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2289#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8047: Implement line-number %-substitution for prompt-string
by GHC 07 Oct '13

07 Oct '13

#8047: Implement line-number %-substitution for prompt-string ------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | 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: | ------------------------------------+------------------------------------- Currently, GHCi supports the following `%`-interpolations: > `:set prompt prompt` > > Sets the string to be used as the prompt in GHCi. Inside prompt, the sequence %s is replaced by the names of the modules currently in scope, and %% is replaced by %. If prompt starts with " then it is parsed as a Haskell String; otherwise it is treated as a literal string. The attached patch implements the `%l` variable, which gets replaced by the current line number of the shown prompt. The motivation being, that compiler messages refer to interactively entered bindings by the line number when they were defined, which are a bit hard to keep track of, e.g.: {{{ λ> :set prompt "\955:%l> " λ:3> let x = () x :: () λ:4> let x = ((),()) x :: ((), ()) λ:5> print xx <interactive>:5:7: Not in scope: ‛xx’ Perhaps you meant ‛x’ (line 4) λ:6> :info x x :: ((), ()) -- Defined at <interactive>:4:5 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8047> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] Batch modify: #8047
by GHC 07 Oct '13

07 Oct '13

Batch modification to #8047 by hvr: Action: reopen -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=8047> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8383: "tagToEnum# (0# ==# 1#) :: Bool" causes CASEFAIL in ghci
by GHC 07 Oct '13

07 Oct '13

#8383: "tagToEnum# (0# ==# 1#) :: Bool" causes CASEFAIL in ghci ----------------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- {{{ rwbarton@adjunction:~/dist/ghc/libraries/base/tests$ echo main | ~/dist/ghc/inplace/bin/ghc-stage2 -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history --interactive -v0 -ignore-dot-ghci tup001d.hs <interactive>: internal error: interpretBCO: hit a CASEFAIL (GHC version 7.7.20130928 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} This causes libraries/base test `tup001` to fail in the same way with WAY=ghci, because the derived instance of Eq for enumeration-like types of more than 10 constructors does something like `x == y = tagToEnum# (getTag x ==# getTag y)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8383> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8417: Pattern matching on OverloadedLists is erratic
by GHC 07 Oct '13

07 Oct '13

#8417: Pattern matching on OverloadedLists is erratic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC accepts Architecture: Unknown/Multiple | invalid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Consider {{{ λ> :set -XOverloadedLists λ> :t \[True] -> 'a' \[True] -> 'a' :: (GHC.Exts.IsList l, GHC.Exts.Item l ~ Bool) => l -> Char λ> :t \[not] -> 'a' \[not] -> 'a' :: GHC.Exts.IsList l => l -> Char }}} The first type is expected, but the second one should include `GHC.Exts.Item l ~ Bool -> Bool` and `Eq (Bool -> Bool)`. Currently e.g. `(\[not] -> True) [id]` evaluates to `True`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8417> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #3553: parallel gc suffers badly if one thread is descheduled
by GHC 07 Oct '13

07 Oct '13

#3553: parallel gc suffers badly if one thread is descheduled -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): > I noticed that if I change nofib/parallel/ray to do its work in a separate thread (see diff), that this "last core slowdown" completely vanishes. Can anybody explain this massive variance? It could be because main runs in a bound thread. Why that makes a huge difference I'm not sure (more context switching?), but that's a likely cause. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3553#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3553: parallel gc suffers badly if one thread is descheduled
by GHC 07 Oct '13

07 Oct '13

#3553: parallel gc suffers badly if one thread is descheduled -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by parcs): * cc: simonmar (added) Comment: I noticed that if I change `nofib/parallel/ray` to do its work in a separate thread (see diff), that this "last core slowdown" completely vanishes. Can anybody explain this massive variance? {{{ #!diff diff --git a/parallel/ray/Main.lhs b/parallel/ray/Main.lhs index a1a72e6..bcd020f 100644 --- a/parallel/ray/Main.lhs +++ b/parallel/ray/Main.lhs @@ -5,10 +5,15 @@ Michaelson for SML, converted to (parallel) Haskell by Kevin Hammond! > import Control.Parallel > import Control.Parallel.Strategies (Strategy, withStrategy, rseq, parBuffer) > import System.Environment +> import Control.Concurrent > main = do -> [detail] <- fmap (map read) getArgs -> putStr (top detail 10.0 7.0 6.0 sc) +> v <- newEmptyMVar +> forkIO $ do +> [detail] <- fmap (map read) getArgs +> putStr (top detail 10.0 7.0 6.0 sc) +> putMVar v () +> takeMVar v > type Coord = (Double,Double,Double) }}} Before patch: {{{ parcs@wolfgang:~/ghc/nofib/parallel/ray$ perf stat ./ray 3000 +RTS -N > /dev/null Performance counter stats for './ray 3000 +RTS -N': 94255.765778 task-clock # 6.343 CPUs utilized 2,686,596 context-switches # 0.029 M/sec 6,592 CPU-migrations # 0.000 M/sec 2,243 page-faults # 0.000 M/sec 338,901,646,069 cycles # 3.596 GHz <not supported> stalled-cycles-frontend <not supported> stalled-cycles-backend 264,852,020,580 instructions # 0.78 insns per cycle 48,676,712,628 branches # 516.432 M/sec 1,114,612,869 branch-misses # 2.29% of all branches 14.859603166 seconds time elapsed }}} After patch: {{{ parcs@wolfgang:~/ghc/nofib/parallel/ray$ perf stat ./ray 3000 +RTS -N > /dev/null Performance counter stats for './ray 3000 +RTS -N': 65701.145514 task-clock # 7.919 CPUs utilized 41,217 context-switches # 0.001 M/sec 101 CPU-migrations # 0.000 M/sec 2,274 page-faults # 0.000 M/sec 242,921,371,383 cycles # 3.697 GHz <not supported> stalled-cycles-frontend <not supported> stalled-cycles-backend 216,526,115,297 instructions # 0.89 insns per cycle 39,079,392,369 branches # 594.805 M/sec 840,462,837 branch-misses # 2.15% of all branches 8.296947901 seconds time elapsed }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3553#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented
by GHC 07 Oct '13

07 Oct '13

#7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented -------------------------------+--------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+--------------------------- Comment (by cjwatson): Things have moved on quite a bit since I last checked, but that ticket does look essentially the same as this one. When I last looked, though, GHCi wasn't actually using the relevant part of libffi in the newExecConItbl path, and I still can't find anything that would do this. Am I missing something here or is bgamari? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7794#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7767: "internal error: evacuate: strange closure type 154886248" crash
by GHC 07 Oct '13

07 Oct '13

#7767: "internal error: evacuate: strange closure type 154886248" crash -----------------------------------+---------------------------------- Reporter: rodlogic | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by schyler): * cc: simonmar (added) * type: feature request => bug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7767#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8297: Allow implicit parameters to take a default value
by GHC 07 Oct '13

07 Oct '13

#8297: Allow implicit parameters to take a default value ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- -XImplicitParams is not that useful except as a type hole. I had an idea where they could be adjusted to be really useful. Consider a function `primes` which uses a wheel sieve. {{{ -- primes: takes a size of the wheel to use, returns a lazy list of primes primes :: Int -> [Int] }}} Your average Joe may not be concerned about the technical details of this function. Why should he have to bother giving a wheel size? The function documentation might say `6` is a good value, but what if some research is done in the future and the library maintainer changes it, later deciding `7` is better? Joe wants to trust the library maintainer, but doesn't want to be burdened by maintaining this arbitrary constant in his code, nor does he like having to pass another parameter to primes. The type of `primes` could be implemented using an implicit parameter like this: {{{ primes -- returns an infinite list of primes primes :: (?wheelSize :: Int) -> [Int] }}} Joe still has to provide a wheelSize however, and now it's even more verbose than before. Wouldn't it be nice if the person who wrote the function could define a default value for `wheelSize`? Joe could use `primes` by itself in his code, whereas Bob, who runs his code on a very powerful server, could tune the performance of his sieve manually by explicitly using `primes where wheelSize = 100`. My suggestion is to develop a syntax which allows functions to define ''default'' values for their implicit parameters. I'm sure the community would have some fun coming up with creative uses for this in their libraries! As an extreme situation, consider the below example; {{{ -- takes a foo, bar, alpha, beta, gamma and epsilon for performance tuning. ouch. aVeryComplexSieveEx :: Int -> Int -> Int -> Int -> Int ... -> r -- f $ aVeryComplexSieveEx 1 2 3 4 ... aVeryComplexSieveEx :: SomeCompulsaryRecordConstructor -> Int -> r -- f $ aVeryComplexSieveEx (SomeCompulsaryRecordConstructor { ... }) 3 }}} vs {{{ aVeryComplexSieveEx :: (?foo :: Int, ?bar :: Int, ?alpha :: Int, ?beta :: Int, ?gamma :: Int) -> Int -> r -- f $ let ?alpha = 1337 in aVeryComplexSieveEx 3 }}} As you can see it would be beneficial for libraries to expose *optional* ways for users to tune internal values in this manner, without having to pass record constructors with many options or make new functions with tiresome numbers of parameters. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8297> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4