January 2014 - ghc-tickets

[GHC] #8628: dynCompileExpr breaks repeated runDecls of the same name
by GHC 17 Jan '14

17 Jan '14

#8628: dynCompileExpr breaks repeated runDecls of the same name ------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | 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: | ------------------------------------+------------------------------------- Using `dynCompileExpr` with `runDecls` from `InteractiveEval` seems to be incredibly problematic when evaluating declarations for the same name. For instance, consider the following code: {{{ runDecls "data X = Y Int" gtry $ runStmt "print (Y 3)" RunToCompletion :: GhcMonad m => m (Either SomeException RunResult) runDecls "data X = Y Int deriving Show" runStmt "print (Y 8)" RunToCompletion }}} As expected, this prints `Y 8` once (the first one fails because `X` is not an instance of `Show`). However, if we insert an arbitrary `dynCompileExpr`, things begin to break: {{{ runDecls "data X = Y Int" gtry $ runStmt "print (Y 3)" RunToCompletion :: GhcMonad m => m (Either SomeException RunResult) runDecls "data X = Y Int deriving Show" _ <- dynCompileExpr "'x'" runStmt "print (Y 8)" RunToCompletion }}} We then get: {{{ No instance for (GHC.Show.Show :Interactive.X) arising from a use of `System.IO.print' Possible fix: add an instance declaration for (GHC.Show.Show :Interactive.X) }}} Which is clearly incorrect - we haven't done anything to change the data declaration. I'm not sure what's going on, but I've tried to investigate into the source of `dynCompileExpr`. It loads `Data.Dynamic` via a `setContext` and then unloads it, and that may be the issue. If we do the following (very similar to the `dynCompileExpr` source), things work fine: {{{ runDecls "data X = Y Int" gtry $ runStmt "print (Y 3)" RunToCompletion :: GhcMonad m => m (Either SomeException RunResult) runDecls "data X = Y Int deriving Show" let stmt = "let __expr = 'x'" Just (ids, hval, fixenv) <- withSession $ \hsc_env -> liftIO $ hscStmt hsc_env stmt vals <- liftIO (unsafeCoerce hval :: IO [Char]) liftIO $ print vals -- thish prints "x", as expected runStmt "print (Y 8)" RunToCompletion }}} I have not tested with GHC API other than 7.6.3, and could not find a bug that was similar to this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8628> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7994: Make foldl into a good consumer
by GHC 17 Jan '14

17 Jan '14

#7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | 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 nomeata): So, this is what we want to happen, somehow. We want to transform code of the form {{{ let f = λ x. let h = f (g1 x) in λ y... h (g2 y) ... in ...f 1 2..... f 3 4 ... }}} into {{{ let f = λ x y. let h = f (g1 x) in ... h (g2 y) ... in ...f 1 2..... f 3 4 ... }}} If `g1` is cheap, this is already done (see `[Arity analysis]` in `CoreArity`). But in order to implement `foldl` in terms of `foldr` and get list fusion for it (which would be nice), this needs to work also when `g1` is expensive. In a slightly more general setting, the transformation would not be ok, e.g. in {{{ let f = λ x. let h = f (g1 x) in λ y... h (g2 y) ... in ...map (f 1).... }}} or {{{ let f = λ x. let h = f (g1 x) in λ y... map h... in ...f 1 2..... f 3 4 ... }}} because the expensive `g1` would no longer be shared. So we want an analysis that * looks at the call-sites of `f` * notices that the demand put on `f` from the body of the let, `C(C¹(S))`, is actually better than the vanilla demand `C(S)`, * makes sure that with this demand put on `f`, its definition (the rhs) now also has this demand (i.e. no sharing lost in the right hand sid), * uses this to mark the `λ y` as one-shot, which will presumably allow the desired optimization. The demand analyser currently analyses the function before the body. One could do a second round, but there is a risk of exponential blow-up. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7994#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7994: Make foldl into a good consumer
by GHC 17 Jan '14

17 Jan '14

#7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | 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 nomeata): Yesterday it looked as if this has magically improved, but at least with the example from the ticket, put into self-contained as follows: {{{#!haskell module Foo( foo ) where import Data.Complex import Prelude hiding (sum, foldl) foldl k z xs = foldr (\v fn z -> fn (k z v)) id xs z {-# INLINE foldl #-} sum = foldl (+) 0 {-# INLINE sum #-} foo x = sum [f n | n <- [1 .. x]] f :: Int -> Complex Double {-# NOINLINE f #-} f n = mkPolar 1 ((2*pi)/fromIntegral n) ^ n }}} I still get bad code: {{{ Foo.$wfoo :: GHC.Prim.Int# -> Data.Complex.Complex GHC.Types.Double [GblId, Arity=1, Str=DmdType <L,U>, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 225 0}] Foo.$wfoo = \ (ww_s1nN :: GHC.Prim.Int#) -> case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.># 1 ww_s1nN) of _ [Occ=Dead] { GHC.Types.False -> letrec { go_a1k0 [Occ=LoopBreaker] :: GHC.Prim.Int# -> Data.Complex.Complex GHC.Types.Double -> Data.Complex.Complex GHC.Types.Double [LclId, Arity=1, Str=DmdType <L,U>] go_a1k0 = \ (x_a1k1 :: GHC.Prim.Int#) -> let { v_ayO [Dmd=<L,U(U(U),U(U))>] :: Data.Complex.Complex GHC.Types.Double [LclId, Str=DmdType] v_ayO = Foo.f (GHC.Types.I# x_a1k1) } in let { ds_dWw [Dmd=<L,C(U)>] :: Data.Complex.Complex GHC.Types.Double -> Data.Complex.Complex GHC.Types.Double [LclId, Str=DmdType] ds_dWw = case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.==# x_a1k1 ww_s1nN) of _ [Occ=Dead] { GHC.Types.False -> go_a1k0 (GHC.Prim.+# x_a1k1 1); GHC.Types.True -> GHC.Base.id @ (Data.Complex.Complex GHC.Types.Double) } } in \ (z_ayQ :: Data.Complex.Complex GHC.Types.Double) -> ds_dWw (Data.Complex.$fFloatingComplex_$s$c+ z_ayQ v_ayO); } in go_a1k0 1 Foo.foo1; GHC.Types.True -> Foo.foo1 } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7994#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4267: Strictness analyser is to conservative about passing a boxed parameter
by GHC 17 Jan '14

17 Jan '14

#4267: Strictness analyser is to conservative about passing a boxed parameter -------------------------------------+------------------------------------ Reporter: tibbe | Owner: nomeata Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.13 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 nomeata): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4267#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5949: Demand analysis attributes manifestly wrong demand type
by GHC 17 Jan '14

17 Jan '14

#5949: Demand analysis attributes manifestly wrong demand type --------------------------------------------+------------------------------ Reporter: batterseapower | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5949#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4267: Strictness analyser is to conservative about passing a boxed parameter
by GHC 17 Jan '14

17 Jan '14

#4267: Strictness analyser is to conservative about passing a boxed parameter -------------------------------------+------------------------------------ Reporter: tibbe | Owner: nomeata Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.13 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 Joachim Breitner <mail@…>): In [changeset:"20b1a0772a6f830cbfba016baea99628a792bb7b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="20b1a0772a6f830cbfba016baea99628a792bb7b" Add testcase for #4267 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4267#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5949: Demand analysis attributes manifestly wrong demand type
by GHC 17 Jan '14

17 Jan '14

#5949: Demand analysis attributes manifestly wrong demand type --------------------------------------------+------------------------------ Reporter: batterseapower | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Joachim Breitner <mail@…>): In [changeset:"19e09df47f48707718150fb9b4b9135ec742bed2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="19e09df47f48707718150fb9b4b9135ec742bed2" Add a test case for #5949 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5949#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8674: User output should not show eta-contracted data instances
by GHC 17 Jan '14

17 Jan '14

#8674: User output should not show eta-contracted data instances ------------------------------------+------------------------------------- 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 {{{ data family Sing (a :: k) data instance Sing (a :: [k]) = SNil data instance Sing Bool = SBool }}} If you load this into ghci and say `:info Sing` you get {{{ :i Sing type role Sing nominal data family Sing (a :: k) -- Defined at T8557.hs:4:1 data instance Sing Bool -- Defined at T8557.hs:6:15 data instance Sing -- Defined at T8557.hs:5:15 }}} The `data instance` is eta-contracted (see `Note [Eta reduction for data family axioms]` in `TcInstDcls`). This is jolly confusing for our users. We should eta-expand before displaying. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8674> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #2283: WIndows: loading objects that refer to DLL symbols
by GHC 17 Jan '14

17 Jan '14

#2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------- Changes (by awson): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2283#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2283: WIndows: loading objects that refer to DLL symbols
by GHC 17 Jan '14

17 Jan '14

#2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------- Changes (by awson): * cc: hvr (added) Comment: This patch solves the problem. The patch is made against 7.6.3 *with* the patch https://ghc.haskell.org/trac/ghc/attachment/ticket/7134/ghc-7.6.3-w64fix.pa… applied. These two also should apply to HEAD cleanly in order. This patch is *especially* important for 64-bit build because it is distributed with mingw-w64 gcc compiler, having {{{__declspec(dllimport)}}} as part of windows api specs in header files. Hence even C/C++ sources built via GHC driver refer to win32 API functions, decorated with {{{__imp_}}} prefix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2283#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0