November 2013 - ghc-tickets

[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

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

27 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: ------------------------------------+------------------------------------ Changes (by khyperia): * cc: hvr (added) Comment: Attempting to take this on as my first ticket, ran into a couple problems. Essentially, using -e eventually calls into code common between GHCi and -e. All the code for the following is in `ghc/InteractiveUI.hs` Relevant control enters in runGHCi, in the `case maybe_exprs` block. Both cases of the block (one with -e arguments, the other with normal interpreting) then call `runCommands`, which eventually filters down to `GhciMonad.runStmt`, which eventually handles the source errors. I am unsure of where to insert the logic to return a nonzero exit code, as putting it in `GhciMonad`/related would also affect normal GHCi. Any tips? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7962#comment:6> 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 26 Nov '13

26 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): Also I think that the call to `cmmLoadIndex` is wrong. It should be {{{(offset `div` rep_bytes)}}}, not just `offset`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6084#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead
by GHC 26 Nov '13

26 Nov '13

#8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Other Architecture: Unknown/Multiple | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The __builtin___clear_cache from GCC is just called __clear_cache with clang, and must be declared. Otherwise the build fails (introduced in https://github.com/ghc/ghc/commit/5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8561> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

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

26 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): Shouldn't the `funInfoArity` function be using `StgFunInfoExtraRev.arity`, not `StgFunInfoExtraFmd.arity`, when `tablesNextToCode` is true? {{{ #!haskell -- Takes the info pointer of a function, returns the function's arity funInfoArity :: DynFlags -> CmmExpr -> CmmExpr funInfoArity dflags iptr = cmmToWord dflags (cmmLoadIndex dflags rep fun_info offset) where fun_info = funInfoTable dflags iptr rep = cmmBits (widthFromBytes rep_bytes) (rep_bytes, offset) | tablesNextToCode dflags = ( pc_REP_StgFunInfoExtraFwd_arity pc , oFFSET_StgFunInfoExtraFwd_arity dflags ) | otherwise = ( pc_REP_StgFunInfoExtraRev_arity pc , oFFSET_StgFunInfoExtraRev_arity dflags ) pc = sPlatformConstants (settings dflags) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6084#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8563: Deriving with PolyKinds broken
by GHC 26 Nov '13

26 Nov '13

#8563: Deriving with PolyKinds broken ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Compiling {{{ {-# LANGUAGE DeriveDataTypeable, PolyKinds #-} module Tagged where import Data.Typeable import Data.Ix newtype Tagged s b = Tagged { unTagged :: b } deriving ( Eq, Ord, Ix, Bounded, Typeable ) }}} gives {{{ Tagged.hs:8:5: ‛Tagged’ is applied to too many type arguments In an expression type signature: Tagged k s b -> Tagged k s b -> Bool In the expression: GHC.Prim.coerce ((==) :: b -> b -> Bool) :: Tagged k s b -> Tagged k s b -> Bool In an equation for ‛==’: (==) = GHC.Prim.coerce ((==) :: b -> b -> Bool) :: Tagged k s b -> Tagged k s b -> Bool Tagged.hs:8:9: ‛Tagged’ is applied to too many type arguments In an expression type signature: Tagged k s b -> Tagged k s b -> Ordering In the expression: GHC.Prim.coerce (compare :: b -> b -> Ordering) :: Tagged k s b -> Tagged k s b -> Ordering In an equation for ‛compare’: compare = GHC.Prim.coerce (compare :: b -> b -> Ordering) :: Tagged k s b -> Tagged k s b -> Ordering Tagged.hs:8:14: ‛Tagged’ is applied to too many type arguments In an expression type signature: (,) (Tagged k s b) (Tagged k s b) -> [] (Tagged k s b) In the expression: GHC.Prim.coerce (range :: (,) b b -> [] b) :: (,) (Tagged k s b) (Tagged k s b) -> [] (Tagged k s b) In an equation for ‛range’: range = GHC.Prim.coerce (range :: (,) b b -> [] b) :: (,) (Tagged k s b) (Tagged k s b) -> [] (Tagged k s b) Tagged.hs:8:18: ‛Tagged’ is applied to too many type arguments In an expression type signature: Tagged k s b In the expression: GHC.Prim.coerce (minBound :: b) :: Tagged k s b In an equation for ‛minBound’: minBound = GHC.Prim.coerce (minBound :: b) :: Tagged k s b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8563> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8