- ghc-tickets - Haskell.org

Re: [GHC] #5113: Huge performance regression of 7.0.2, 7.0.3 and HEAD over 7.0.1 and 6.12 (MonoLocalBinds)
by GHC 11 Feb '13

11 Feb '13

#5113: Huge performance regression of 7.0.2, 7.0.3 and HEAD over 7.0.1 and 6.12 (MonoLocalBinds) --------------------------------------+------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: performance, MonoLocalBinds Os: Linux | Architecture: x86 Failure: Runtime performance bug | Difficulty: Testcase: perf/should_run/T5113 | Blockedby: Blocking: | --------------------------------------+------------------------------------- Comment(by simonpj@…): commit 33683ba9367e03b6b051f1c0c694fd8bf244a759 {{{ Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Mon Feb 11 08:38:12 2013 +0000 Extra comment about the fix to Trac #5113 compiler/specialise/Specialise.lhs | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5113#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7192: Bug in -fregs-graph with -fnew-codegen
by GHC 11 Feb '13

11 Feb '13

#7192: Bug in -fregs-graph with -fnew-codegen -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: benl Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: 4258 | Related: -------------------------------+-------------------------------------------- Comment(by simonmar): Replying to [comment:13 shelarcy]: > Where is a separated ticket? #7679 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7192#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7498: panic : Register allocator: out of stack slots (need 147)
by GHC 11 Feb '13

11 Feb '13

#7498: panic : Register allocator: out of stack slots (need 147) ----------------------------------+----------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: powerpc Failure: Building GHC failed | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Changes (by PHO): * status: new => patch Comment: I [https://github.com/phonohawk/ghc/commit/c1feb5f9b82ab05a128ecb7678d2da3db07… ported] the above patch to PPC: {{{ % git fetch git://github.com/phonohawk/ghc.git ticket-7498 }}} While x86 version did not seemingly retarget table-branches, I was not sure that was intended or not so I decided to retarget them in my PPC version. At least my patch works for my Darwin/PPC box. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7498#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7359: unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1)
by GHC 10 Feb '13

10 Feb '13

#7359: unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1) ----------------------------+----------------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Component: libraries/unix Version: 7.4.1 | Keywords: unix package Os: MacOS X | Architecture: x86_64 (amd64) Failure: Other | Testcase: Blockedby: | Blocking: Related: | ----------------------------+----------------------------------------------- Changes (by george.colpitts): * keywords: => unix package -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7359#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7359: unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1)
by GHC 10 Feb '13

10 Feb '13

#7359: unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1) ----------------------------+----------------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Component: libraries/unix Version: 7.4.1 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: Other | Testcase: Blockedby: | Blocking: Related: | ----------------------------+----------------------------------------------- Changes (by george.colpitts): * cc: george.colpitts@… (added) Comment: Any chance of a fix for this? Many packages depend on unix and these packages can't be installed on Mac OS with the latest Haskell Platform -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7359#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7379: rangeTest test fails on Windows
by GHC 09 Feb '13

09 Feb '13

#7379: rangeTest test fails on Windows ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by rassilon): Yeah, CWchar for CSigAtomic is a typo. wchar_t is always 16 bits on Windows OSs. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7379#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7353: Make system IO interruptible on Windows
by GHC 09 Feb '13

09 Feb '13

#7353: Make system IO interruptible on Windows ---------------------------------+------------------------------------------ Reporter: joeyadams | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 Keywords: | Os: Windows Architecture: Unknown/Multiple | Failure: Incorrect result at runtime Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by ihameed): * cc: idhameed@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7353#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7595: Static flags code needs cleanup
by GHC 09 Feb '13

09 Feb '13

#7595: Static flags code needs cleanup -----------------------------+---------------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Component: Driver Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- While reading through the source code I noticed that code responsible for handling static flags could use some refactoring: * there are two modules that handle static flags: [[GhcFile(compiler/main/StaticFlags.hs)]] and [[GhcFile(compiler/main/StaticFlagParser.hs)]]. This is about 300 lines of code total and can be easily placed within a single file, especially that division of functions between these two files is sometimes confusing. * [[GhcFile(compiler/main/StaticFlags.hs)]] contains code responsible for handling dynamic flags. I will merge code from [[GhcFile(compiler/main/StaticFlagParser.hs)]] into into [[GhcFile(compiler/main/StaticFlags.hs)]], create a [[GhcFile(compiler/main/StaticFlags.hs-boot)]] to break module dependency cycles and move the code for handling dynamic flags to [[GhcFile(compiler/main/DynFlags.hs)]] -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7595> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

Re: [GHC] #5793: make nofib awesome
by GHC 09 Feb '13

09 Feb '13

#5793: make nofib awesome --------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: _|_ Component: NoFib benchmark suite | Version: Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: 5794 Related: | --------------------------------------+------------------------------------- Comment(by simonmar): Replying to [comment:22 morabbin]: > Not sure if this is the place to report this, but without > {{{ > cabal install html > }}} > `nofib-analyse` won't compile, as it uses `Text.Html`. Where is the correct place to put this dependency? Moving `nofib-analyse` out into a Cabal package might be a good idea, and would resolve this. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5793#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5793: make nofib awesome
by GHC 08 Feb '13

08 Feb '13

#5793: make nofib awesome --------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: _|_ Component: NoFib benchmark suite | Version: Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: 5794 Related: | --------------------------------------+------------------------------------- Description changed by dterei: Old description: > Nofib is the standard tool GHC developers use to benchmark changes to the > compiler. Its overall design is OK but it's had no love and care for many > years and has bittrotted such that it isn't useful in a lot of > situations. > > This task is about making nofib useful again. > > The breakdown for this is something like: > > 1. Think and maybe fix nofib framework design. It has 'ways' which I > think correspond to compilation method but more in the sense of 'dynamic' > vs 'static', seems it may not suite being able to use ways for 'fasm' vs > 'fllvm'. There is also the concept of 'modes' which corresponds to > different benchmark input. So 'normal' and 'slow' for getting different > run-times. At moment no easy way to select which benchmark groups to run, > so may want to change that. I guess we should just decide, what knobs do > we want to be able to easily tweak, and see how well the current design > allows that. > > 2. Fixup the runtimes for benchmarks to be significant. This might be > best done by changing the way we run benchmarks and collect results to > make sure they are meaningful. > > E.g., Lots of great discussion and links to papers on this thread > > http://www.haskell.org/pipermail/ghc-devs/2013-February/000307.html > > 3. Above task is to fix normal but we may want to fixup slow as well and > perhaps add a 'fast' mode where benchmarks run in around 1 second. > > 4. Maybe add more benchmarks to the suite (text, bytestring, performance > regressions from ghc testsuite, vector....) New description: Nofib is the standard tool GHC developers use to benchmark changes to the compiler. Its overall design is OK but it's had no love and care for many years and has bittrotted such that it isn't useful in a lot of situations. This task is about making nofib useful again. The breakdown for this is something like: 1. Think and maybe fix nofib framework design. It has 'ways' which I think correspond to compilation method but more in the sense of 'dynamic' vs 'static', seems it may not suite being able to use ways for 'fasm' vs 'fllvm'. There is also the concept of 'modes' which corresponds to different benchmark input. So 'normal' and 'slow' for getting different run-times. At moment no easy way to select which benchmark groups to run, so may want to change that. I guess we should just decide, what knobs do we want to be able to easily tweak, and see how well the current design allows that. '''Note''' there is a shake build system attached that does a lot of this (done by Neil Mitchell!). An explanation of it can be found here: http://neilmitchell.blogspot.com/2013/02/a-nofib-build-system-using- shake.html The design discussion of it is mostly lost as it was done on private email sorry. 2. Fixup the runtimes for benchmarks to be significant. This might be best done by changing the way we run benchmarks and collect results to make sure they are meaningful. E.g., Lots of great discussion and links to papers on this thread http://www.haskell.org/pipermail/ghc-devs/2013-February/000307.html 3. Above task is to fix normal but we may want to fixup slow as well and perhaps add a 'fast' mode where benchmarks run in around 1 second. 4. Maybe add more benchmarks to the suite (text, bytestring, performance regressions from ghc testsuite, vector....) -- -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5793#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0