June 2013 - ghc-tickets

[GHC] #7894: Crash on :i M.->
by GHC 07 Jun '13

07 Jun '13

#7894: Crash on :i M.-> -----------------------------+---------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHCi crash | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- {{{ Prelude> :i M.-> ghc: panic! (the 'impossible' happened) (GHC version 7.7.20130427 for x86_64-unknown-linux): isDataOcc: check me -> }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7894> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 2

Re: [GHC] #5996: fix for CSE
by GHC 07 Jun '13

07 Jun '13

#5996: fix for CSE ---------------------------------+------------------------------------------ Reporter: michalt | Owner: simonpj Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.5 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by ian@…): commit cfe92a8f8482a3c863c3bddc4be894b09fb972ff {{{ Author: Ian Lynagh <ian(a)well-typed.com> Date: Thu Jun 6 17:55:35 2013 +0100 Remove old representation of CSEnv; part of #5996 compiler/coreSyn/CoreUtils.lhs | 80 ---------------------------------------- compiler/simplCore/CSE.lhs | 72 +----------------------------------- 2 files changed, 1 insertions(+), 151 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5996#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7636: threadStackUnderflow: not enough space for return values
by GHC 06 Jun '13

06 Jun '13

#7636: threadStackUnderflow: not enough space for return values -------------------------+-------------------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.2 | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- While filling a {{{Control.Concurrent.STM.TBQueue}}} (stm-2.4) with values the system crashes with the following message: {{{ internal error: threadStackUnderflow: not enough space for return values (GHC version 7.4.2 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7636> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 15

[GHC] #7959: Panic on deriving nullary typeclass
by GHC 06 Jun '13

06 Jun '13

#7959: Panic on deriving nullary typeclass -------------------------------+-------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- {{{ {-# LANGUAGE NullaryTypeClasses #-} class C }}} Both `data A deriving C` and `deriving instance C` cause panic. Patch attached. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7959> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7702: Memory Leak in CoreM (CoreWriter)
by GHC 06 Jun '13

06 Jun '13

#7702: Memory Leak in CoreM (CoreWriter) -----------------------------------------+---------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time performance bug | Blockedby: Blocking: | Related: -----------------------------------------+---------------------------------- While running HERMIT on extended examples, we noticed that the CoreWriter component of CoreM is building up unevaluated SimplCount expressions. Attached is a one line patch to make the field in the CoreWriter record strict, which fixes the leak. Also attached are heap profiles before and after to verify the fix. (You'll notice we have other memory leaks in HERMIT to address, the important bit being the big CoreWriter peak is gone in after.pdf.) These were generated by running a large number of HERMIT transformations in a batch, with HERMIT calling ghc with +RTS -hT -RTS. I'm not sure how this affects compilation time or allocation when SimplCount is not the VerySimplCount constructor. Would the nofib suite answer these questions? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7702> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 17

Re: [GHC] #7272: PolyKinds and mutually recursive modules
by GHC 06 Jun '13

06 Jun '13

#7272: PolyKinds and mutually recursive modules -------------------------------+-------------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: polykinds/T7272 | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by xnyhps): There appears (to me) to be a small typo in this commit, although I can't think of any bugs that are caused by it: [https://github.com/ghc/ghc/commit/2c207b6f60ba5d271f400747256e4a32ca8f7e63#… compiler/types/Type.lhs:1231] {{{ cmpTypeX env (ForAllTy tv1 t1) (ForAllTy tv2 t2) = cmpTypeX env (tyVarKind tv1) (tyVarKind tv1) }}} It compares `tv1`'s kind to itself, instead of to `tv2`'s kind. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7272#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7966: 'make distclean' does not work in nofib
by GHC 06 Jun '13

06 Jun '13

#7966: 'make distclean' does not work in nofib -----------------------------+---------------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Component: NoFib benchmark suite Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I noticed that `make distclean` and `make maintainer-clean` don't work for nofib because `distclean` and `maintainer-clean` targets are not defined in the `nofib-analyse/Makefile`. This seems easy to fix - it's enough to change `clean:` to `clean distclean maintainer-clean:` in the mentioned `Makefile`. After this fix is applied it turns out that the cleaning commands leave some garbage in the nofib tree: - output files from cachegrind are not removed. This can be fixed by adding `cachegrind.out*` on line 250 in `mk/ghc-paths.mk` - these files are not deleted: {{{ real/maillist/addresses.tex shootout/fasta/fasta-c shootout/fasta/fasta.stdout shootout/k-nucleotide/fasta-c shootout/k-nucleotide/knucleotide-input2500000.txt shootout/reverse-complement/fasta-c shootout/reverse-complement/revcomp-c shootout/reverse-complement/revcomp-input2500000.txt shootout/reverse-complement/reverse-complement.stdout }}} I'm not sure on the best way of fixing the second issue so I'm not attaching my own patch. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7966> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 06 Jun '13

06 Jun '13

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. ---------------------------------+------------------------------------------ Reporter: jpbernardy | Owner: monoidal Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords: deriving | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC rejects valid program Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): Two more thoughts * You point out in #7931, this already works for standalone deriving, which is a bit odd. Standalone and non-standalone deriving should behave pretty much the same. * When I say "works" what I mean is that, for nullary types, all methods `foo` get this definition: {{{ foo = error "Void foo" }}} This is done in `TcGenDeriv.mkRdrFunBind`. Several points: * Is this always the right thing to do? For every method, and every class? Eg for `Read` it wasn't; see #7931. Needs checking. * We could also generate {{{ foo x y = error "Void foo" }}} (ie with the error inside the lambdas) which isn't quite the same. I'm not sure which is right. * Including the name of the type constructor in the error message would be a lot more helpful. Thanks! Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7401#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7965: The 'impossible' happened!
by GHC 06 Jun '13

06 Jun '13

#7965: The 'impossible' happened! -------------------------------+-------------------------------------------- Reporter: adit | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.1 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- I'm working on a haskell package (code here: https://github.com/egonschiele/rdioh) and when I try to build it I get this error consistently: In order, the following will be installed: rdioh-0.1.1 (reinstall) changes: hspec-1.4.4 added Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring rdioh-0.1.1... Building rdioh-0.1.1... Preprocessing executable 'rdioh' for rdioh-0.1.1... [2 of 5] Compiling Rdioh.Models ( src/Rdioh/Models.hs, dist/build/rdioh/rdioh-tmp/Rdioh/Models.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for x86_64-apple-darwin): nameModule show{tv a1rK} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Failed to install rdioh-0.1.1 cabal: Error: some packages failed to install: rdioh-0.1.1 failed during the building phase. The exception was: ExitFailure 1 make: *** [all] Error 1 I'm on OSX v 10.8.2. Darwin Kernel Version 12.2.1: Thu Oct 18 12:13:47 PDT 2012; root:xnu-2050.20.9~1/RELEASE_X86_64 x86_64 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7965> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 06 Jun '13

06 Jun '13

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. ---------------------------------+------------------------------------------ Reporter: jpbernardy | Owner: monoidal Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords: deriving | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC rejects valid program Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): Thanks for helping. Concerning your question, I think it would be fine for `-XEmptyDataDecls` to imply that we can derive `Eq` etc for them. No need for a second flag. What would be good would be some documentation in the user manual (in the empty data decls section) that says what is derived for the standard build-in classes. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7401#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0