- ghc-tickets - Haskell.org

Re: [GHC] #1572: Make it easy to find documentation for GHC and installed packages
by GHC 27 Jan '13

27 Jan '13

#1572: Make it easy to find documentation for GHC and installed packages ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by morabbin): Bump. I agree with Ian re packages doco, but where are we with GHC docs? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1572#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1555: Reverse do notation: lexer bug?
by GHC 27 Jan '13

27 Jan '13

#1555: Reverse do notation: lexer bug? --------------------------------+------------------------------------------- Reporter: dons | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Parser) | Version: 6.6.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Easy (less than 1 hour) Testcase: | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- Changes (by morabbin): * failure: => None/Unknown Comment: Bump; what's the dealio? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1555#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6024: Allow defining kinds alone, without a datatype
by GHC 25 Jan '13

25 Jan '13

#6024: Allow defining kinds alone, without a datatype ----------------------------------------+----------------------------------- Reporter: dreixel | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.5 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ----------------------------------------+----------------------------------- Changes (by ross): * cc: ross@… (added) Comment: I'm particularly interested in using * in a kind definition, which should be possible with a distinct syntax for kind definitions. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6024#comment:4> 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 25 Jan '13

25 Jan '13

#7542: GHC doesn't optimize (strict) composition with id ---------------------------------+------------------------------------------ Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): The previous two commits improve the situation a bit; both were triggered by looking at the code from this example, thanks. I'm far from sure that we get perfect code now. But I'm also convinced that this is the wrong way to solve this problem: check out [wiki:NewtypeWrappers]. Meanwhile do have a go with HEAD and see if you get better code now. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7542#comment:9> 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 25 Jan '13

25 Jan '13

#7542: GHC doesn't optimize (strict) composition with id ---------------------------------+------------------------------------------ Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): Also this: {{{ commit 7a1480c7c590d4d2fa7a105a4eebf299e921e056 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Tue Jan 22 22:43:22 2013 +0000 Allow eta-reduction of eval'd functions if of arity 1 See Note [Eta reduction of an eval'd function] in CoreUtils. This doesn't fix Trac #7542, but that was the ticket that pointed out this infelicity. >--------------------------------------------------------------- compiler/coreSyn/CoreUtils.lhs | 24 ++++++++++++++++++++++-- 1 files changed, 22 insertions(+), 2 deletions(-) diff --git a/compiler/coreSyn/CoreUtils.lhs b/compiler/coreSyn/CoreUtils.lhs index 7017f70..9b527e7 100644 --- a/compiler/coreSyn/CoreUtils.lhs +++ b/compiler/coreSyn/CoreUtils.lhs @@ -1712,8 +1712,14 @@ tryEtaReduce bndrs body --------------- fun_arity fun -- See Note [Arity care] - | isLocalId fun && isStrongLoopBreaker (idOccInfo fun) = 0 - | otherwise = idArity fun + | isLocalId fun + , isStrongLoopBreaker (idOccInfo fun) = 0 + | arity > 0 = arity + | isEvaldUnfolding (idUnfolding fun) = 1 + -- See Note [Eta reduction of an eval'd function] + | otherwise = 0 + where + arity = idArity fun --------------- ok_lam v = isTyVar v || isEvVar v @@ -1737,6 +1743,20 @@ tryEtaReduce bndrs body ok_arg _ _ _ = Nothing \end{code} +Note [Eta reduction of an eval'd function] +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +In Haskell is is not true that f = \x. f x +because f might be bottom, and 'seq' can distinguish them. + +But it *is* true that f = f `seq` \x. f x +and we'd like to simplify the latter to the former. This amounts to +the rule that + * when there is just *one* value argument, + * f is not bottom +we can eta-reduce \x. f x ===> f + +This turned up in Trac #7542. }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7542#comment:8> 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 25 Jan '13

25 Jan '13

#7542: GHC doesn't optimize (strict) composition with id ---------------------------------+------------------------------------------ Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj@…): commit 35f1fc957d152c520c90c6bd2330266e57578eb2 {{{ Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Tue Jan 22 22:46:33 2013 +0000 Allow CaseElim if the case binder is the next thing to be eval'd This makes CaseElim happen a bit more often. See Note [Case binder next] in Simplify. This came up when investigating Trac #7542. compiler/simplCore/Simplify.lhs | 32 ++++++++++++++++++++++++++------ 1 files changed, 26 insertions(+), 6 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7542#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7622: Unregisterised builds don't support LLVM backend
by GHC 25 Jan '13

25 Jan '13

#7622: Unregisterised builds don't support LLVM backend -----------------------------+---------------------------------------------- Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The LLVM backend should work in unregisterised mode. Apparently the driver isn't allowing it to be chosen though. Need to investigate this claim and allow LLVM again if true. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7622> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1524: stdcall fails on MacOS
by GHC 25 Jan '13

25 Jan '13

#1524: stdcall fails on MacOS --------------------------------------------+------------------------------- Reporter: chak | Owner: Type: bug | Status: closed Priority: lowest | Milestone: _|_ Component: Compiler | Version: 6.7 Resolution: fixed | Keywords: Os: MacOS X | Architecture: x86 Failure: None/Unknown | Difficulty: Unknown Testcase: ffi012, 1288, 2276, 2276_ghci | Blockedby: Blocking: | Related: --------------------------------------------+------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1524#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7557: Default implementation for a type class function missing when profiling is enabled
by GHC 25 Jan '13

25 Jan '13

#7557: Default implementation for a type class function missing when profiling is enabled ---------------------------------+------------------------------------------ Reporter: JohnWiegley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Urgh. So many dependencies! Can you: * Do `ghc --show-iface` on `Data/Git/Internal.hi` * Compile `Data.Git.Internal` with `-ddump-simpl` * Compile `Data.Git.Blob` with `-ddump-ds -ddump-simpl` and let me have the output? thanks. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7557#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7561: Unnecessary Heap Allocations - Slow Performance
by GHC 25 Jan '13

25 Jan '13

#7561: Unnecessary Heap Allocations - Slow Performance -------------------------------+-------------------------------------------- Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------------+-------------------------------------------- Comment(by simonpj): There seem to be two separate issues here 1. A profiled program runs a lot faster than a non-profiled one 2. Two variants of a program that depends on the (complex) vector library run with very different speeds. Can anyone help boil either (1) or (2) down into a smaller program, or otherwise characterise what's going on? I'm out of bandwidth. Using `-ticky` profiling might help guide you to where the allocation is happening. Thanks Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7561#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0