February 2014 - ghc-tickets

Re: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell
by GHC 10 Feb '14

10 Feb '14

#7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: closed Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: fixed | Related Tickets: Operating System: | Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | th/T7021 | Blocking: | -------------------------+------------------------------------------------- Comment (by goldfire): Here is the relevant commit to TH: http://git.haskell.org/packages/template- haskell.git/commitdiff/57b662c3efd8579595c8642fce2d4cd60ba4ec0b In short, we've equated predicates with types (`type Pred = Type`) and added a new constructor to `Type`, `EqualityT :: Type`, which represents `(~)`. Thus, this would break any code that uses predicates in Template Haskell. That's a fair amount of breakage, but, as I said, I think this change is forward-thinking, especially given that predicates and types are the same type within GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7021#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2823: Another arity expansion bug
by GHC 10 Feb '14

10 Feb '14

#2823: Another arity expansion bug --------------------------------------------+------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.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 Comment: It seems that this has been fixed in ghc-7.6.3 or before: {{{ T2823.foo [InlPrag=NOINLINE] :: forall a. GHC.Classes.Eq a => a -> a [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType AS] T2823.foo = \ (@ a) _ (x :: a) -> x T2823.bar [InlPrag=INLINE[1] (sat-args=1)] :: forall a. GHC.Classes.Eq a => a -> a [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType LL] T2823.bar = \ (@ a) ($dEq :: GHC.Classes.Eq a) (eta :: a) -> let { p [Dmd=Just L] :: (a, a) [LclId, Str=DmdType] p = T2823.foo @ (a, a) (GHC.Classes.$fEq(,) @ a @ a $dEq $dEq) (eta, eta) } in let { $dEq1 [Dmd=Just A] :: GHC.Classes.Eq (a, a) [LclId, Str=DmdType] $dEq1 = GHC.Classes.$fEq(,) @ a @ a $dEq $dEq } in case T2823.foo @ ((a, a), (a, a)) (GHC.Classes.$fEq(,) @ (a, a) @ (a, a) $dEq1 $dEq1) (p, p) of _ { (x, _) -> case x of _ { (x1, ds2) -> x1 } } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2823#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2915: Arity is smaller than need be
by GHC 10 Feb '14

10 Feb '14

#2915: Arity is smaller than need be --------------------------------------------+------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: infoneeded Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.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: --------------------------------------------+------------------------------ Changes (by nomeata): * status: new => infoneeded Comment: I don’t understand this ticket: Why should `f` have arity 1? It would be eta-expanded, and we’d be losing work! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2915#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3697: Method selectors aren't floated out of loops
by GHC 10 Feb '14

10 Feb '14

#3697: Method selectors aren't floated out of loops --------------------------------------------+------------------------------ Reporter: rl | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.13 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 * difficulty: => Unknown * resolution: => fixed Comment: With todays HEAD, I get good code: {{{ T3697.foo = \ (@ a) ($dEq :: GHC.Classes.Eq a) ($dNum :: GHC.Num.Num a) (as :: [a]) -> let { ds :: a [LclId, Str=DmdType] ds = GHC.Num.fromInteger @ a $dNum T3697.foo1 } in let { lvl :: a -> a -> GHC.Types.Bool [LclId, Str=DmdType] lvl = GHC.Classes./= @ a $dEq } in let { lvl1 :: a -> a -> a [LclId, Str=DmdType] lvl1 = GHC.Num.- @ a $dNum } in letrec { go [Occ=LoopBreaker] :: [a] -> [a] [LclId, Arity=1, Str=DmdType <S,1*U>] go = \ (ds1 :: [a]) -> case ds1 of _ [Occ=Dead] { [] -> GHC.Types.[] @ a; : y ys -> let { x :: a [LclId, Str=DmdType] x = lvl1 y y } in case lvl x ds of _ [Occ=Dead] { GHC.Types.False -> go ys; GHC.Types.True -> GHC.Types.: @ a x (go ys) } }; } in go as }}} Given the age of the bug, I don’t dare to guess what has fixed this. Also, hard to make a useful testcase here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3697#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3698: Bad code generated for zip/filter/filter loop
by GHC 10 Feb '14

10 Feb '14

#3698: Bad code generated for zip/filter/filter loop --------------------------------------------+------------------------------ Reporter: rl | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.13 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 * difficulty: => Unknown * resolution: => fixed Comment: The new callarity analysis successfully eta-expands the monomorphic code. For the polymorphic code, there is nothing we can do, as guest mentions in comment:1. So I guess this can be closed. (I did not create a test case for this because these things are hard to test, and it is a standard application fo the callarity analysis, nothing tricky going on here.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3698#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3924: Strictness analyser missing useful strictness
by GHC 10 Feb '14

10 Feb '14

#3924: Strictness analyser missing useful strictness -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.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 nomeata): * difficulty: => Unknown Comment: This looks like it could be solved by the new callartiy analysis. It does not, though, because * all the functions are top-level functions, and callartiy analysis only looks at local functions, and * they are mutually recursive, which the callarity analysis does not handle yet. Both could possibly be fixed, but both carry an implementation and maintenance cost, I’d like to do that lazily, i.e. depending on real-world use cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3924#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5809: Arity analysis could be better
by GHC 10 Feb '14

10 Feb '14

#5809: Arity analysis could be better --------------------------------------------+------------------------------ Reporter: simonmar | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.5 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 Comment: Judging from the code, the new callartiy analysis should do exactly that (see that `block` is called with two arguments). Unfortunately, there is no small example here to verify this; but I’m optimistic. If you find that it does not work with today’s HEAD, I’d like to hear about it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5809#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7542: GHC doesn't optimize (strict) composition with id
by GHC 10 Feb '14

10 Feb '14

#7542: GHC doesn't optimize (strict) composition with id --------------------------------------------+------------------------------ Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.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 nomeata): The simple example from the ticket: {{{ (#) :: (b -> c) -> (a -> b) -> a -> c (#) f g = f `seq` g `seq` \x -> f (g x) foo :: (a -> b) -> [a] -> [b] foo f = map (id # f) }}} produces {{{ T7542.foo = \ (@ a) (@ b) (f :: a -> b) (eta :: [a]) -> GHC.Base.map @ a @ b (\ (eta1 :: a) -> f eta1) eta }}} without `-fpedantic-bottoms` and {{{ T7542.foo = GHC.Base.map }}} with, which looks fine. The same happens to the more elaborate example in comment:2 (middle section), `-fpedantic-bottoms` preserves the semantics and with that we get `map2 = map`. So it seems that situation has improved and we can close the ticket (which should not discourage anyone who finds a situation that needs fixing to open it again). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7542#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5983: Libraries installed in wrong place
by GHC 10 Feb '14

10 Feb '14

#5983: Libraries installed in wrong place -----------------------------------+---------------------------------- Reporter: r0ml | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.4.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by darchon): Probably fixed by #8266 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5983#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5982: Incorrect dynamic library name in OSX
by GHC 10 Feb '14

10 Feb '14

#5982: Incorrect dynamic library name in OSX -----------------------------------+---------------------------------- Reporter: r0ml | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.4.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by darchon): Probably now fixed with #8266 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5982#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0