January 2014 - ghc-tickets

Re: [GHC] #5498: Generalized newtype deriving allows creating of instances I can't create by hand
by GHC 07 Jan '14

07 Jan '14

#5498: Generalized newtype deriving allows creating of instances I can't create by hand -----------------------------------------------+--------------------------- Reporter: dterei | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: deriving/should_fail/T5498 | Difficulty: Unknown Blocking: | Blocked By: 1496 | Related Tickets: -----------------------------------------------+--------------------------- Changes (by simonpj): * testcase: => deriving/should_fail/T5498 Comment: Indeed. The program is indeed rejected, although the error message is not fantastic. I've added it as a test. I think you can enable GND in Safe Haskell. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5498#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function
by GHC 07 Jan '14

07 Jan '14

#1498: Optimisation: eliminate unnecessary heap check in recursive function -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: 4258 Blocking: | Related Tickets: 8326 -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => 8326 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1498#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5498: Generalized newtype deriving allows creating of instances I can't create by hand
by GHC 07 Jan '14

07 Jan '14

#5498: Generalized newtype deriving allows creating of instances I can't create by hand -------------------------------------+------------------------------------ Reporter: dterei | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 1496 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: This should not be possible any more: In the type `intIso :: forall c. c t -> c Int`, `c`’s type parameter is considered to be nominal, so `coerce` will not allow changing `c (Down a)` to `c a` any more. And GND is now based on `Coercible`... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5498#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5075: CPR optimisation for sum types if only one constructor is used
by GHC 07 Jan '14

07 Jan '14

#5075: CPR optimisation for sum types if only one constructor is used -------------------------------------+------------------------------------ Reporter: batterseapower | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.0.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 simonpj): An 8% increase in binary size is pretty dramatic. I wonder why that is happening. (Not every easy to find out.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5075#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5075: CPR optimisation for sum types if only one constructor is used
by GHC 07 Jan '14

07 Jan '14

#5075: CPR optimisation for sum types if only one constructor is used -------------------------------------+------------------------------------ Reporter: batterseapower | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.0.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): In that case, let me add some numbers related to sum type CPR in local functions. With current master [4d70840d/ghc], enabling CPR for sum types has this effect: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ansi +8.6% +0.5% 0.00 0.00 +0.0% awards +8.6% +0.2% 0.00 0.00 +0.0% cacheprof +8.0% +0.2% -3.1% -3.1% +0.0% calendar +8.6% +0.2% 0.00 0.00 +0.0% circsim +8.5% +1.1% -8.7% -8.7% -2.0% cryptarithm1 +8.7% -3.8% +0.5% +0.5% +0.0% cse +8.6% +0.2% 0.00 0.00 +0.0% fibheaps +8.6% -0.3% 0.02 0.02 +0.0% fluid +7.7% +3.4% 0.01 0.01 +0.0% fulsom +8.3% +0.1% 0.19 0.19 -31.2% hidden +8.3% +1.8% +3.4% +6.2% +0.0% kahan +8.1% +0.1% 0.17 0.17 +0.0% listcompr +8.6% +0.4% 0.06 0.05 +0.0% listcopy +8.6% +0.4% 0.07 0.06 +0.0% mandel +7.5% +0.3% 0.05 0.05 +0.0% mandel2 +8.7% +33.8% 0.00 0.00 +0.0% parser +8.1% +1.7% 0.02 0.02 +0.0% primetest +8.7% -0.2% 0.07 0.07 +0.0% reptile +8.5% +0.2% 0.01 0.01 +0.0% rewrite +8.5% +0.1% 0.02 0.02 +0.0% rfib +8.7% +0.6% 0.02 0.02 +0.0% spectral-norm +8.5% +0.7% -0.6% -0.6% +0.0% symalg +8.3% +0.2% 0.01 0.01 +0.0% tak +8.6% +1.3% 0.01 0.01 +0.0% transform +8.3% +0.1% +0.0% +0.0% +0.0% -------------------------------------------------------------------------------- Min +6.8% -3.8% -11.3% -11.3% -31.2% Max +8.7% +33.8% +3.9% +6.2% +6.1% Geometric Mean +8.4% +0.4% -1.8% -1.8% -0.4% }}} So one quite extreme degradation, and otherwise minor losses. If I make sure that join points do not get the CPR information unless the expression they are a join point for does, we get this change (relative to the same baseline): {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- cacheprof +8.0% +0.3% -4.7% -4.7% +1.8% calendar +8.6% +0.1% 0.00 0.00 +0.0% circsim +8.5% +0.2% -8.4% -8.4% -2.0% cryptarithm1 +8.6% -3.8% +1.5% +1.5% +0.0% cse +8.6% +0.2% 0.00 0.00 +0.0% fibheaps +8.5% -0.3% 0.03 0.03 +0.0% fulsom +8.2% -3.7% 0.19 0.19 -31.2% kahan +8.1% -0.2% 0.17 0.17 +0.0% listcompr +8.6% +0.4% 0.07 0.06 +0.0% listcopy +8.6% +0.4% 0.07 0.06 +0.0% maillist +8.6% +0.0% 0.04 0.04 +16.0% mandel +7.4% +0.2% 0.05 0.05 +0.0% parser +8.1% +1.7% 0.02 0.02 +0.0% primetest +8.6% -0.2% 0.07 0.07 +0.0% rewrite +8.5% +0.1% 0.01 0.01 +0.0% -------------------------------------------------------------------------------- Min +6.8% -3.8% -8.4% -8.4% -31.2% Max +8.7% +1.7% +3.2% +3.4% +16.0% Geometric Mean +8.3% -0.0% -2.0% -1.9% -0.2% }}} This looks quite different now: A few losses, but much smaller than before. A mean of zero, and more gains than before. Unfortunately, the code size increase is still there... If it were not for the code size increase, I’d suggest to merge these changes: Fewer special cases in transformations is a good thing. But it is probably not worth the code size increase, is it? (Just for the record: In theory it is possible that CPR’ing a non-sum-type can destroy the join-point-property of a let. But it does not seem to happen: If I enable the cpr-join-point-fix, but keep CPR for sum types disabled, nofib does not record any change whatsoever.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5075#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function
by GHC 07 Jan '14

07 Jan '14

#1498: Optimisation: eliminate unnecessary heap check in recursive function -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by NeilMitchell): http://neilmitchell.blogspot.co.uk/2014/01/optimising-haskell-for-tight- inner-loop.html - the code in version 4/version 5 includes a small example of the bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1498#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1978: Error message: Undefined reference to `XXX_closure'
by GHC 07 Jan '14

07 Jan '14

#1978: Error message: Undefined reference to `XXX_closure' ----------------------------------------------+--------------------------- Reporter: Andriy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC rejects valid program | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------------+--------------------------- Comment (by carter): huh, have you tested with GHC head? Is it resolved in 7.7 currently? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1978#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1978: Error message: Undefined reference to `XXX_closure'
by GHC 06 Jan '14

06 Jan '14

#1978: Error message: Undefined reference to `XXX_closure' ----------------------------------------------+--------------------------- Reporter: Andriy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC rejects valid program | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------------+--------------------------- Comment (by MichalGajda): Here is a patch that fixed the issue in Pandoc, to give idea how it looks: {{{ diff -u -r orig/pandoc-1.11.1/src/Text/Pandoc/Readers/Markdown.hs pandoc-1.11.1/src/Text/Pandoc/Readers/Markdown.hs --- orig/pandoc-1.11.1/src/Text/Pandoc/Readers/Markdown.hs 2014-01-06 23:09:47.928990710 +0000 +++ pandoc-1.11.1/src/Text/Pandoc/Readers/Markdown.hs 2014-01-06 21:33:46.963590240 +0000 @@ -63,7 +63,10 @@ -> String -- ^ String to parse (assuming @'\n'@ line endings) -> Pandoc readMarkdown opts s = - (readWith parseMarkdown) def{ stateOptions = opts } (s ++ "\n\n") + readWithParser def { stateOptions = opts } (s ++ "\n\n") + +-- | Helper function to avoid missing closure bug. See GHC bug #1978 +readWithParser state s = readWith parseMarkdown state s -- | Read markdown from an input string and return a pair of a Pandoc document -- and a list of warnings. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1978#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5361: regSpill: out of spill slots!
by GHC 06 Jan '14

06 Jan '14

#5361: regSpill: out of spill slots! -------------------------------------+------------------------------------- Reporter: markwright | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: regSpill panic Operating System: Linux | impossible Type of failure: Compile-time | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: http://hackage.haskell.org/package/SHA| Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by carter): indeed, changing a compiler flag is a work around, not a fix. So its ameliorated for 7.8, but can we really consider this "fixed" ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5361#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8654: Exponential-long compilation of code with Implicit params
by GHC 06 Jan '14

06 Jan '14

#8654: Exponential-long compilation of code with Implicit params -------------------------------------+------------------------------------- Reporter: akamaus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: ImplicitParams | Operating System: Unknown/Multiple slowness | Type of failure: Compile-time Architecture: Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Some time ago I stumbled upon GHC hanging on my code. After some experiments I managed to minify it to: {-# LANGUAGE ImplicitParams #-} data D = D Int deriving Show slow_to_compile :: IO () slow_to_compile = do tst1 <- return 1 let ?tst1 = tst1 let ?tst2 = tst1 let ?tst3 = tst1 let ?tst4 = tst1 let ?tst5 = tst1 let ?tst6 = tst1 let ?tst7 = tst1 print $ D ?tst1 It compiles, but takes a while. Every additional binding doubles compilation time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8654> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1