- ghc-tickets - Haskell.org

Re: [GHC] #6135: Unboxed Booleans
by GHC 07 Jun '13

07 Jun '13

#6135: Unboxed Booleans -------------------------------+-------------------------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #605 -------------------------------+-------------------------------------------- Comment(by jstolarek): I spent some time on figuring out why my patch works. Here's what I come up with (hopefully I got things right). Previously the !PrimOps of type `Compare` used to return `Bool` (`prelude/PrimOp.lhs`): {{{ getPrimOpResultInfo :: PrimOp -> PrimOpResultInfo getPrimOpResultInfo op = case (primOpInfo op) of Compare _ _ -> ReturnsAlg boolTyCon }}} I changed them to return `Int#`: {{{ getPrimOpResultInfo :: PrimOp -> PrimOpResultInfo getPrimOpResultInfo op = case (primOpInfo op) of Compare _ _ -> ReturnsPrim (tyConPrimRep intPrimTyCon) }}} This is how primops are converted from Core to STG (`CoreToStg.lhs`, `coreToStgApp` function): {{{ res_ty = exprType (mkApps (Var f) args) app = case idDetails f of -- Some primitive operator that might be implemented as a library call. PrimOpId op -> ASSERT( saturated ) StgOpApp (StgPrimOp op) args' res_ty }}} Previously `res_ty` was set to `Bool`, now it is `Int#`. STG representation of a primop is converted to Cmm (`StgCmmExpr.hs`) by `cgExpr` function: {{{ cgExpr (StgOpApp op args ty) = cgOpApp op args ty }}} So previously `cgOpApp` function matched this guard: {{{ | ReturnsAlg tycon <- result_info , isEnumerationTyCon tycon -- c.f. cgExpr (...TagToEnumOp...) = do dflags <- getDynFlags tag_reg <- newTemp (bWord dflags) cgPrimOp [tag_reg] primop args emitReturn [tagToClosure dflags tycon (CmmReg (CmmLocal tag_reg))] }}} and now it matches this one: {{{ | ReturnsPrim rep <- result_info = do dflags <- getDynFlags res <- newTemp (primRepCmmType dflags rep) cgPrimOp [res] primop args emitReturn [CmmReg (CmmLocal res)] }}} The main difference being that there is no call to `tagToClosure`, which was the goal of this ticket - to return an unboxed unlifted value instead of a closure that needs to be entered or have its tag examined. This leads me to a conclusion: since `tagToClosure` is an implementation of `tagToEnum#` primop, there should be no performance difference between the previous version of code, where call to `tagToEnum#` was generated implicitly by the code generator, and the new primop wrappers, which make the call to `tagToEnum#` explicit. In theory at least, because kahan for some reason is slower. I'm investigating this but so far I found nothing that would be obvious. And I'm also working on identifying code that is no longer necessary. One thing that keeps me puzzled is that there are still primops that return `Bool`, e.g. {{{ primop SameMutVarOp "sameMutVar#" GenPrimOp MutVar# s a -> MutVar# s a -> Bool }}} I'm not sure if this allows me to remove special case that Simon M. mentioned. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:68> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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 06 Jun '13

06 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