December 2013 - ghc-tickets

Re: [GHC] #8006: Asynchronous exception rethrown synchronously inside runStmt
by GHC 04 Dec '13

04 Dec '13

#8006: Asynchronous exception rethrown synchronously inside runStmt -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by edsko): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8006#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8006: Asynchronous exception rethrown synchronously inside runStmt
by GHC 04 Dec '13

04 Dec '13

#8006: Asynchronous exception rethrown synchronously inside runStmt -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): If that fixes the bug, I'm ok with closing this ticket. I doubt we're going to pursue a more "correct" fix, unless any problems arise with this one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8006#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 04 Dec '13

04 Dec '13

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by nomeata): * owner: => nomeata Comment: Interesting corner case: With nested CPR enabled, `GHC.TopHandler` in base fails to compile with: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.7.20131203 for x86_64-unknown-linux): mkWWcpr: non-algebraic or open body type a{tv a28d} [tv] but CPR type tm1() }}} The problem is this code: {{{ #!haskell case {__pkg_ccall_GC base shutdownHaskellAndExit GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld #)}_d2VI 255 ds_d2VF eta_XG of _ [Occ=Dead, Dmd=<L,A>] { (# ds_d2VG [OS=OneShot] #) -> (# ds_d2VG, GHC.Tuple.() #) }}} stemming from {{{ #!haskell foreign import ccall "shutdownHaskellAndSignal" shutdownHaskellAndSignal :: CInt -> CInt -> IO () }}} which then is `unsafeCoerce#`’ed to `a`, with note explanation {{{ -- we have to use unsafeCoerce# to get the 'IO a' result type, since the -- compiler doesn't let us declare that as the result type of a foreign export. }}} There are a few ways to attack this issue: 1. We allow `a` in the return type of a foreign export (but maybe overkill to do that just for this code). 2. We try to forget CPR information when things pass through `unsafeCoerce#` (but that is just a {{{`cast`}}} in Core, and may be hard to detect reliably. Maybe every coercion that has a `UnivCo representational` inside?) 3. We re-write that code in base, e.g. instead of `unsafeCoerce` use `... >> error "I’m still alive?"`. 4. We simply turn the `panic` into a warning. I guess 2. makes most sense, because we don’t want other instances of `unsafeCoerce#` to cause this error either. For now I’ll do 4, to not get stuck compiling base. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3384: Add HsSyn prettyprinter tests
by GHC 04 Dec '13

04 Dec '13

#3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------ Reporter: igloo | Owner: kseo Type: task | Status: new Priority: normal | Milestone: _|_ Component: Test Suite | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by kseo): * owner: => kseo -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3384#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3384: Add HsSyn prettyprinter tests
by GHC 04 Dec '13

04 Dec '13

#3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Test Suite | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by kseo): * failure: => None/Unknown Comment: I'd like to work on this task as my first patch to GHC. I think the idea suggested by dfranke in #1966 is a good starting point. Take some large Haskell projects and: 1. Parse them 1. Pretty-print them 1. Reparse the output 1. Pretty-print again and verify that step 3 succeeds and the outputs of steps 2 and 4 match. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3384#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3625: GHCI doesn't work with dtrace on OS X
by GHC 04 Dec '13

04 Dec '13

#3625: GHCI doesn't work with dtrace on OS X ---------------------------------+------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by carter): * cc: hvr (added) Comment: is this resolved with ghc 7.7 head? Has anyone tested dtrce with head? if not i'll try to find the time to test it out soon. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3625#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 03 Dec '13

03 Dec '13

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by nomeata): Run nofib the first time, mixed results: {{{ binary-trees -1.3% +0.6% +7.7% +7.5% +0.0% hidden -1.3% -0.5% -0.3% -0.5% +0.0% mandel -1.2% -9.2% 0.10 0.10 +0.0% nucleic2 -1.0% -2.6% 0.11 0.11 +0.0% reverse-complem -1.3% +4.9% 0.21 0.22 +0.0% -------------------------------------------------------------------------------- Min -1.4% -9.2% -6.3% -6.6% -4.5% Max -1.0% +4.9% +7.7% +7.5% +0.0% Geometric Mean -1.3% -0.0% +0.5% +0.6% -0.1% }}} The gain in mandel seems to come from a a few more unboxed results in `Data.Complex`, in particular the return types of `$w$sphase` and `$w$smagnitued` turns from `Double` to `Double#` (and likewise the `Float`-specializations). And why the new chance for that? Because `$fFloatingComplex` (which is a CAF for `D# 0.0`) and other constants are inlined (and thus no longer shared). Not sure why that part changed, and it seems that this is not related to ''nested''CPR... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8006: Asynchronous exception rethrown synchronously inside runStmt
by GHC 03 Dec '13

03 Dec '13

#8006: Asynchronous exception rethrown synchronously inside runStmt -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Edsko de Vries <edsko@…>): In [changeset:"586bc85538cf12048137c2693da7c9fe3ca481ef/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="586bc85538cf12048137c2693da7c9fe3ca481ef" Mask async exceptions in forkM_ See #8006 for the reason why. This is not a fix as such; more of a workaround. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8006#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7307: Share top-level code for strings
by GHC 03 Dec '13

03 Dec '13

#7307: Share top-level code for strings -------------------------------------+------------------------------------ Reporter: simonpj | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by parcs): * owner: => parcs Comment: I will try to do this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7307#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8576: Improve deriving error messages
by GHC 03 Dec '13

03 Dec '13

#8576: Improve deriving error messages -------------------------------------------+------------------------------- Reporter: nomeata | Owner: nomeata Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type checker) | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Instead of {{{ No instance for (Eq (Int -> Bool)) arising from the 'deriving' clause of a data type declaration Possible fix: add an instance declaration for (Eq (Int -> Bool)) or use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Eq Foo) }}} for {{{ data Foo = Foo Int (Int -> Bool, Bool) deriving Eq }}} we want something like {{{ No instance for (Eq (Int -> Bool)) arising from the second field of the constructor Foo Possible fix: add an instance declaration for (Eq (Int -> Bool)) or use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Eq Foo) }}} where we tell the user more precisely from where in its data type the problem comes from. Should be possible by beefing up `CtOrigin`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8576> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4