- ghc-tickets - Haskell.org

Re: [GHC] #7962: "ghc -e <invalid expression>" should return non-zero exit status
by GHC 28 Nov '13

28 Nov '13

#7962: "ghc -e <invalid expression>" should return non-zero exit status ------------------------------------+------------------------------------ Reporter: timmaxw | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+------------------------------------ Comment (by simonmar): Patch reviewed, so leaving in the 'new' state. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7962#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7962: "ghc -e <invalid expression>" should return non-zero exit status
by GHC 28 Nov '13

28 Nov '13

#7962: "ghc -e <invalid expression>" should return non-zero exit status ------------------------------------+------------------------------------ Reporter: timmaxw | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+------------------------------------ Comment (by simonmar): The patch looks ok. I would refactor it a bit, like this: {{{ when (not success) $ maybe (return ()) lift sourceErrorHandler runCommands' eh sourceErrorHandler gCmd }}} Don't forget to add a test to testsuite/tests/ghci. If the testsuite isn't working right now, search for a ticket about that, and if there isn't one, make one :-) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7962#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7962: "ghc -e <invalid expression>" should return non-zero exit status
by GHC 28 Nov '13

28 Nov '13

#7962: "ghc -e <invalid expression>" should return non-zero exit status ------------------------------------+------------------------------------ Reporter: timmaxw | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+------------------------------------ Comment (by khyperia): Patch created and attached. The test suite currently does not run on my Windows machine ("tee: standard output: Permission denied", followed by a hang), so I was unable to run the validation script. As this is my first patch, please tell me what I did wrong :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7962#comment:7> 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 28 Nov '13

28 Nov '13

#6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: patch Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 8313 | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): I updated the patch to accommodate `fun` with a temporary variable. Let me know what you think. This optimization only triggers four times inside the nofib testsuite: twice in `lift:Print.lhs` and twice in `n-body:Main.hs`. According to subsequent nofib runs, the runtime of these two programs is not affected by the optimization. Compile time doesn't seem to have been affected either. But, as mentioned before, the runtime of the program in #8313 is significantly improved: 0.75s vs 3.9s. I also uploaded a test for the testsuite. The test is essentially a modified version of the program in #8313 which checks that the program returns the expected result. But I'm not confident that this is the best way to go about testing this optimization. Do you have a better idea? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6084#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4426: Simplify the rules for implicit quantification
by GHC 27 Nov '13

27 Nov '13

#4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: patch Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7880 -------------------------------------+------------------------------------ Comment (by monoidal): Patch updated for current HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4426#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8565: New GeneralisedNewtypeDeriving needs help with higher rank types
by GHC 27 Nov '13

27 Nov '13

#8565: New GeneralisedNewtypeDeriving needs help with higher rank types ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE RankNTypes, GeneralizedNewtypeDeriving #-} module Foo where class C a where op :: (forall b. b -> a) -> a newtype T x = MkT x deriving( C ) }}} With the new "coerce" implementation of GND, this fails: {{{ Foo.hs:7:31: Cannot instantiate unification variable ‛b0’ with a type involving foralls: (forall b. b -> T x) -> T x Perhaps you want ImpredicativeTypes In the expression: GHC.Prim.coerce (op :: (forall (b :: *). b -> x) -> x) :: (forall (b :: *). b -> T x) -> T x In an equation for ‛op’: op = GHC.Prim.coerce (op :: (forall (b :: *). b -> x) -> x) :: (forall (b :: *). b -> T x) -> T x }}} We want to coerce betweeen {{{ (forall b. b -> x) -> x ~R (forall b. b -> T x) -> T x }}} There are two difficulties with the new `coerce` approach: * Regarded as source code, instance declaration {{{ instance C x => C (T x) where op = coerce (op :: (forall b. b -> x) -> x) }}} requires impredicative instantiation. * We probably don't have a decomposition rule for `Coercible (forall a. t1) (forall a. t2)` There is no difficulty in principle here, but it's not quite obvious what the best approach to a fix is. But it would be good to fix before release; we don't want to break `conduit` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8565> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

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

27 Nov '13

#6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: patch Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 8313 | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Replying to [comment:30 simonmar]: > Thanks for revising the patch. > > I spotted one problem: you're referring to `fun` in two places, which might duplicate some code. The original patch put it in a temp variable for this reason. It's a good idea to peer at the Cmm code being generated to see whether it looks as you expect. Ah, okay. I will reinstate the temp variable for `fun` and then run nofib again, this time more carefully. > We'll need a test for this in `testsuite/codeGen`. Okay. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6084#comment:31> 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 27 Nov '13

27 Nov '13

#6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: patch Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 8313 | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Thanks for revising the patch. I spotted one problem: you're referring to `fun` in two places, which might duplicate some code. The original patch put it in a temp variable for this reason. It's a good idea to peer at the Cmm code being generated to see whether it looks as you expect. We'll need a test for this in `testsuite/codeGen`. The nofib results are slightly suspicious: this patch should never increase allocation, but there's a 0.1% increase for `cacheprof`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6084#comment:30> 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 27 Nov '13

27 Nov '13

#6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: patch Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 8313 | Related Tickets: -------------------------------------+------------------------------------ Changes (by parcs): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6084#comment:29> 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 27 Nov '13

27 Nov '13

#6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 8313 | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Here's a patch that fixes up Simon's original patch. It fixes three issues with the original patch: 1. The offset passed to `cmmLoadIndex` should be in units of the object's representation size, not necessarily bytes. So we divide `offset` by `rep_bytes`. 2. The `tablesNextToCode` logic was reversed. 3. We weren't untagging and dereferencing the function closure before passing it to `funInfoArity` and `entryCode`. With these three changes, the code in #8313 has a significant speed improvement. Before (that is, with vanilla GHC), the `auto` case would take 2.15s and the `manual` case 4.0s. Now, the `manual` case takes 0.75s. nofib doesn't seem to show a significant improvement in program runtime, but nofib compile times are down an average of 1.5% with a maximum improvement of 8%. I may be misinterpreting the results, however. int-e, how did you trigger the "PAP object entered!" error? I haven't come across it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6084#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0