March 2013 - ghc-tickets

[GHC] #7802: kindFunResult in monad transformer
by GHC 31 Mar '13

31 Mar '13

#7802: kindFunResult in monad transformer -------------------------------+-------------------------------------------- Reporter: tobsan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.6.1 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- This is probably related to the existing (fixed?) bug(s) about kindFunResult, but better safe than sorry. I was writing a brainfuck interpreter, and tried changing this code: {{{ getptrval = gets mem >>= \a -> gets ptr >>= lift . readArray a }}} to this (which probably wouldn't even work): {{{ getptrval = liftM2 (lift . readArray) (gets ptr) (gets mem) }}} which gives this error message from GHC: {{{ Brainfuck.hs:53:21:ghc: panic! (the 'impossible' happened) (GHC version 7.6.1 for x86_64-unknown-linux): kindFunResult <<details unavailable>> }}} Related type information: {{{ type BFMonad a = StateT BFState IO a data BFState = BF { pc, ptr :: Int, mem :: IOUArray Int Int, program :: UArray Int Char } }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7802> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #607: Ticky-ticky profiling
by GHC 29 Mar '13

29 Mar '13

#607: Ticky-ticky profiling -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: tim Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Resolution: None | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Difficult (2-5 days) Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by nfrisby): This seems to have been fixed at some point; ticky at least compiles. Are we retaining this ticket for some reason? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/607#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7796: improve dead code elimination in CorePrep
by GHC 29 Mar '13

29 Mar '13

#7796: improve dead code elimination in CorePrep -----------------------------+---------------------------------------------- Reporter: nfrisby | Owner: nfrisby Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: #4962 #5433 -----------------------------+---------------------------------------------- #4962 is about generating code for (and allocating at runtime!) bindings that are kept alive only by RULEs even though the RULEs are useless downstream of .hi file generation. Simon Marlow's patch for #5433 switched to a custom dead code eliminator, since the "(case) binder swap" in OccurAnal was creating breaking some code generator invariants. However, that custom dead code generator doesn't do a dependency analysis, so a letrec like this {{{ let f = [g] \r [...] -> ... g = [g] \r [...] -> ... in ... g ... }}} is sent to the code generator ''without dropping'' `f`. A patch to use a dependency analysis in CorePrep's dead code eliminator improves allocation for several nofib programs (largest: cryptarithm2, knights, fem). {{{ Min -0.0% -4.2% -7.7% -7.7% -5.9% Max +0.0% +0.0% +4.3% +4.3% +14.3% Geometric Mean -0.0% -0.1% -0.2% -0.2% +0.2% }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7796> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #3333: GHCi doesn't load weak symbols
by GHC 29 Mar '13

29 Mar '13

#3333: GHCi doesn't load weak symbols --------------------------------------+------------------------------------- Reporter: heatsink | Owner: akio Type: bug | Status: patch Priority: normal | Milestone: 7.6.2 Component: GHCi | Version: 6.10.4 Keywords: weak, dynamic loading | Os: Linux Architecture: x86 | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: 3658 | Blocking: Related: | --------------------------------------+------------------------------------- Comment(by akio): Replying to [comment:24 igloo]: Why is this blocked by #3658? Isn't the ability to load a static C++ object file independent to the ability to use the system linker? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3333#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7553: ghc fails to terminate with -O2 or greater
by GHC 28 Mar '13

28 Mar '13

#7553: ghc fails to terminate with -O2 or greater ---------------------------------+------------------------------------------ Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: duplicate | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: ---------------------------------+------------------------------------------ Changes (by amosrobinson): * cc: amos.robinson@… (added) * status: new => closed * resolution: => duplicate Comment: Yes, vector fold with a list accumulator will trigger the ForceSpecConstr bug, so this is definitely a duplicate of #5550. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7553#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5550: GHC infinite loop when compiling vector
by GHC 28 Mar '13

28 Mar '13

#5550: GHC infinite loop when compiling vector ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: merge Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.2.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by amosrobinson): * cc: amos.robinson@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5550#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5550: GHC infinite loop when compiling vector
by GHC 28 Mar '13

28 Mar '13

#5550: GHC infinite loop when compiling vector ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: merge Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.2.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by amosrobinson): * status: new => merge Comment: I have implemented Roman's suggestion of having an upper bound for recursive types. So in this example: {{{ loop :: SPEC -> [Int] -> [Int] -> [Int] loop SPEC z [] = z loop SPEC z (x:xs) = loop SPEC (x:z) xs }}} The only good call pattern is {{{loop SPEC (_:_) _}}} but once that is specialised, there's another call pattern {{{loop SPEC (_:(_:_)) _}}} and so on. So we just find the maximum number of recursive constructors in the arguments, and if it's greater than the limit (default 3) we discard the pattern. I only check the recursive count if ForceSpecConstr is on for the current function. This doesn't really matter, but if ForceSpecConstr isn't on it should terminate anyway because of the max count. Does this look OK to you, Roman? https://github.com/ghc/ghc/commit/81d55a9ec28d9d7c8b1492516ebd58c5ff90c0e8 On Fri, Mar 8, 2013 at 7:20 PM, Roman Leshchinskiy <rl(a)cse.unsw.edu.au> wrote: > If you want to prevent infinite specialisation, then IMO the way > to do it would be by not specialising more than a few times on > recursive types but still specialising on tuples, Maybe, Either > and friends as much as possible. That would guarantee termination > without imposing an artificial bound. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5550#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5550: GHC infinite loop when compiling vector
by GHC 28 Mar '13

28 Mar '13

#5550: GHC infinite loop when compiling vector ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.2.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by amos.robinson@…): commit 81d55a9ec28d9d7c8b1492516ebd58c5ff90c0e8 {{{ Author: Amos Robinson <amos.robinson(a)gmail.com> Date: Thu Mar 28 12:37:42 2013 +1100 Fix non-termination of SpecConstr (see #5550). ForceSpecConstr will now only specialise recursive types a finite number of times. There is a new option -fspec-constr-recursive, with a default value of 3. compiler/main/DynFlags.hs | 4 ++ compiler/specialise/SpecConstr.lhs | 64 ++++++++++++++++++++++++++---------- 2 files changed, 50 insertions(+), 18 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5550#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1480: Template Haskell should allow reification of modules
by GHC 27 Mar '13

27 Mar '13

#1480: Template Haskell should allow reification of modules ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by ddfisher): * cc: ddf1991@… (added) Comment: I'm working on writing a low-boilerplate FFI from Python to Haskell and would find this very useful as well. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1480#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
by GHC 26 Mar '13

26 Mar '13

#6084: Add stg_ap_pnnv and related call patterns ---------------------------------+------------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by nfrisby): * cc: nfrisby (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6084#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0