- ghc-tickets - Haskell.org

Re: [GHC] #1752: CSE can create space leaks by increasing sharing (was: space leak caused by $ vs. () with -O2)
by GHC 29 Jan '13

29 Jan '13

#1752: CSE can create space leaks by increasing sharing --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6.1 Resolution: wontfix | Keywords: Os: Windows | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: Known issue with CSE, not likely to ever get fixed. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1752#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1747: debugger: :trace is wasting time
by GHC 29 Jan '13

29 Jan '13

#1747: debugger: :trace is wasting time -------------------------------------------+-------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: GHCi | Version: 6.6.1 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------------------+-------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: Not much to be gained by having this ticket open, so I'll close it. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1747#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7282: polykinds error: Found `k' but expected `k'
by GHC 29 Jan '13

29 Jan '13

#7282: polykinds error: Found `k' but expected `k' ---------------------------------------+------------------------------------ Reporter: HolgerReinhardt | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Testcase: Blockedby: | Blocking: Related: | ---------------------------------------+------------------------------------ Comment(by simonpj@…): commit d79c0c48bb64f85ab45adcc3158be9f71845f974 {{{ Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Tue Jan 29 08:43:02 2013 +0000 Improve consistency checking for associated type-family instances The "consistency" in this case is beteween the instance head and the associated type instance head, which is made trickier by the presence of kind variables that are not explicitly mentioned in the class head. See Note [Checking consistent instantiation] in TcInstDcls This fixes Trac #7282. compiler/typecheck/TcInstDcls.lhs | 239 ++++++++++++++++++++++------------- compiler/typecheck/TcTyClsDecls.lhs | 37 ------ 2 files changed, 154 insertions(+), 122 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7282#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4210: LLVM: Dynamic Library Support
by GHC 28 Jan '13

28 Jan '13

#4210: LLVM: Dynamic Library Support ---------------------------------+------------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by dterei): Simon Marlow said in an email: {{{ Also I believe even if it works, the code that LLVM generates for -dynamic is not very good. This is because it makes every symbol reference a dynamic reference, whereas the NCG only makes dynamic references for symbols in other packages. It ought to be possible to fix this by using the right symbol declarations (I'm guessing, I haven't looked into it). }}} I can't remember if this is correct or not but recording here to look into when I have time as part of dynamic support in LLVM. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4210#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

28 Jan '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 simonpj): Roman, we are stalled on this one. It is some interaction of the `vector` library with `SpecConstr`. Might you investigate, and suggest how to progress? We have three separate tickets about it, so it's clearly getting in the way of `vector` being widely used. Thanks Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5550#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

28 Jan '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 simonpj): See also #7553, #7555. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5550#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1262: RecursiveDo in Template Haskell
by GHC 28 Jan '13

28 Jan '13

#1262: RecursiveDo in Template Haskell ----------------------------------------+----------------------------------- Reporter: philip.weaver@… | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.6 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ----------------------------------------+----------------------------------- Comment(by simonpj): We just need someone to update the `template-haskell` library to support `mdo`, and add support to `DsMeta` and `Convert`. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1262#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1870: ghc-6.8.1 panics compiling regex-tdfa-0.93
by GHC 28 Jan '13

28 Jan '13

#1870: ghc-6.8.1 panics compiling regex-tdfa-0.93 -------------------------------+-------------------------------------------- Reporter: ChrisKuklewicz | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.1 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => wontfix Comment: Yes let's close it. I don't think anyone else has complained that `regex- tdfa` doesn't compile. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1870#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7524: Erroneous repeated kind variable in conflicting type family instance error message
by GHC 28 Jan '13

28 Jan '13

#7524: Erroneous repeated kind variable in conflicting type family instance error message ------------------------------------------------+--------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Difficulty: Unknown Testcase: polykinds/T7524 | Blockedby: Blocking: | Related: #7587 ------------------------------------------------+--------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => fixed * testcase: => polykinds/T7524 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7524#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7524: Erroneous repeated kind variable in conflicting type family instance error message
by GHC 28 Jan '13

28 Jan '13

#7524: Erroneous repeated kind variable in conflicting type family instance error message ----------------------------------------------+----------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: #7587 ----------------------------------------------+----------------------------- Comment(by simonpj@…): commit a98e51ecf51d1a93d48a8a10d35827edfd9d8c28 {{{ Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Mon Jan 28 08:18:28 2013 +0000 More refactoring of FamInst/FamInstEnv; finally fixes Trac #7524 Quite a bit of tidying up here; the fix to #7524 is actually only a small part. * Be fully clear that the cab_tvs in a CoAxBranch are not fresh. See Note [CoAxBranch type variables] in CoAxiom. * Use CoAxBranch to replace the ATDfeault type in Class. CoAxBranch is perfect here. This change allowed me to delete quite a bit of boilerplate code, including the corresponding IfaceSynType. * Tidy up the construction of CoAxBranches, and when FamIntBranch is freshened. The latter onw happens only in FamInst.newFamInst. * Tidy the tyvars of a CoAxBranch when we build them, done in FamInst.mkCoAxBranch. See Note [Tidy axioms when we build them] in that module. This is what fixes #7524. Much niceer now. compiler/iface/BinIface.hs | 7 - compiler/iface/IfaceSyn.lhs | 31 ++--- compiler/iface/MkIface.lhs | 21 +-- compiler/iface/TcIface.lhs | 29 ++--- compiler/typecheck/FamInst.lhs | 142 ++++++++++++++------- compiler/typecheck/TcGenGenerics.lhs | 9 +- compiler/typecheck/TcInstDcls.lhs | 50 +++----- compiler/typecheck/TcRnDriver.lhs | 4 +- compiler/typecheck/TcTyClsDecls.lhs | 21 ++-- compiler/types/Class.lhs | 20 +--- compiler/types/CoAxiom.lhs | 31 ++++- compiler/types/Coercion.lhs | 1 - compiler/types/FamInstEnv.lhs | 106 +--------------- compiler/vectorise/Vectorise/Generic/PAMethods.hs | 4 +- compiler/vectorise/Vectorise/Generic/PData.hs | 10 +- 15 files changed, 204 insertions(+), 282 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7524#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0