February 2016 - ghc-tickets

Re: [GHC] #7803: Superclass methods are left unspecialized
by GHC 06 Feb '16

06 Feb '16

#7803: Superclass methods are left unspecialized -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Here is a nofib comparison based on 38af3d1db2889423a12a2232b9d52181bba23d75 with and without the following patch, {{{#!patch diff --git a/compiler/simplCore/SimplCore.hs b/compiler/simplCore/SimplCore.hs index 6badbf8..c573b45 100644 --- a/compiler/simplCore/SimplCore.hs +++ b/compiler/simplCore/SimplCore.hs @@ -182,7 +182,7 @@ getCoreToDo dflags (base_mode { sm_phase = InitialPhase , sm_names = ["Gentle"] , sm_rules = rules_on -- Note [RULEs enabled in SimplGently] - , sm_inline = False + , sm_inline = True , sm_case_case = False }) -- Don't do case-of-case transformations. -- This makes full laziness work better }}} Unfortunately things don't look terribly promising, {{{ Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min -0.3% -95.0% -0.6% -1.2% 0.0% Max +0.9% +10.6% +14.3% +14.3% +100.0% Geometric Mean +0.4% -2.8% +1.6% +1.5% +0.8% }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7803#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #797: nofib tests fail on Windows due to different EOL convention in output files
by GHC 06 Feb '16

06 Feb '16

#797: nofib tests fail on Windows due to different EOL convention in output files -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6 Component: NoFib benchmark | Version: 6.4.1 suite | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * failure: => None/Unknown * resolution: fixed => * owner: igloo => @@ -1,1 +1,1 @@ - Now fixed in the 6.6 branch. + New description: -- Comment: NoFib on Windows fails for me using ghc-8.1 with `expected stdout not matched by reality`. Seems to be a line ending issue. This is the command I try to run, following instructions from [wiki:Building/RunningNoFib#Benchmarking]: {{{ cd nofib make boot make exeext=.exe }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/797#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7803: Superclass methods are left unspecialized
by GHC 06 Feb '16

06 Feb '16

#7803: Superclass methods are left unspecialized -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've started a pair of builds; I'll put up nofib results once they have finished. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7803#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7803: Superclass methods are left unspecialized
by GHC 06 Feb '16

06 Feb '16

#7803: Superclass methods are left unspecialized -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Can someone take another look at this ticket? It sounds like Simon's suggestion just needs to be merged. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7803#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7666: excessive space and time usage for rendering (somewhat) deeply nested Docs
by GHC 05 Feb '16

05 Feb '16

#7666: excessive space and time usage for rendering (somewhat) deeply nested Docs -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: dterei Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.6.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by j.waldmann): * cc: ekmett (added) Comment: simplified test case entered into pretty's bug tracker: https://github.com/haskell/pretty -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7666#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10289: compiling huge HashSet hogs memory
by GHC 05 Feb '16

05 Feb '16

#10289: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Compiling a huge (~2.5k elements) set with GHC-7.10.1 or GHC-head and unordered-containers-0.2.5.1 or unordered-containers-head takes way too much memory. Here is a [https://github.com/zudov/html5-entity/blob/unordered- containers/src/Text/Html/Entity/Data/EntitySet.hs file] which I am trying to compile. I've also set up a [https://travis- ci.org/zudov/html5-entity/builds/58063328 travis build] which demonstrates the behaviour with different versions of GHC and unordered-containers. Further I would be referring to [https://travis- ci.org/zudov/html5-entity/jobs/58063332 this build-job] which uses GHC-7.10.1 and unordered-containers-0.2.5.1. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L397 Compilation] with default optimization options takes around [https ://travis-ci.org/zudov/html5-entity/jobs/58063332#L408 12GB] of memory. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L367 Compilation] with `-O0` takes around [https://travis- ci.org/zudov/html5-entity/jobs/58063332#L378 400MB]. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L457 Compilation] with `-O2` takes around [https://travis- ci.org/zudov/html5-entity/jobs/58063332#L468 12GB] of memory. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L487 Compilation] with `-O2 -fignore-interface-pragmas` takes around [https ://travis-ci.org/zudov/html5-entity/jobs/58063332#L498 500MB] of memory, which solves the problem. When the build uses GHC-7.8.4, neither of this hogging [https://travis- ci.org/zudov/html5-entity/jobs/58063330 occurs]. Another interesting observation is that [https://travis- ci.org/zudov/html5-entity/jobs/58063330#L339 compiling] [https://github.com/zudov/html5-entity/blob/unordered- containers/src/Text/Html/Entity/Data/EntityMap.hs HashMap] of the same size, doesn't cause memory hogging even with `-O2`. This attracted my attention as `HashSet` is implemented in terms of `HashMap`. I reported the issue to `unordered-containers` as well: [https://github.com/tibbe/unordered-containers/issues/100 link]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10289> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9638: Speed up Data.Char.isDigit
by GHC 05 Feb '16

05 Feb '16

#9638: Speed up Data.Char.isDigit -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Runtime hour) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `isDigit` is currently defined like this: {{{#!hs isDigit :: Char -> Bool isDigit c = c >= '0' && c <= '9' }}} This will short-circuit the right way if you're looking for digits mixed with spaces, but the wrong way if you're looking for digits mixed with letters. It also requires a conditional jump to do that short-circuiting (confirmed by inspecting the assembly). It should be better to use an unsigned comparison instead: {{{#!hs isDigit :: Char -> Bool isDigit c = (fromIntegral (ord c) :: Word) - 48 <= 9 }}} The interesting section looks like this {{{ movq 7(%rbx),%rax addq $-48,%rax cmpq $9,%rax setbe %al movzbl %al,%eax shlq $3,%rax movq ghczmprim_GHCziTypes_Bool_closure_tbl(%rax),%rbx addq $8,%rbp jmp *(%rbp) }}} or like this with -fllvm: {{{ movq 7(%rbx), %rax addq $-48, %rax cmpq $10, %rax sbbq %rax, %rax andq $8, %rax movq ghczmprim_GHCziTypes_Bool_closure_tbl(%rax), %rbx movq 8(%rbp), %rax addq $8, %rbp jmpq *%rax # TAILCALL }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9638> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11538: Wrong constants in LL code for big endian targets
by GHC 05 Feb '16

05 Feb '16

#11538: Wrong constants in LL code for big endian targets -------------------------------------+------------------------------------- Reporter: wereHamster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (LLVM) | Keywords: | Operating System: Unknown/Multiple Architecture: mips | Type of failure: Building GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm trying to compile GHC for a big endian MIPS target (MIPS 24Kc, Atheros AR9330). The generated code for the `negateFloat` function has the following line: `%ln3uf = fsub float 0x0000000000000080, %ln3ue` But the constant should be `0x8000000000000000` instead. See todays discussion in #ghc between wereHamster and rwbarton for more details and possible hints how/where to fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11538> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11374: `-Woverlapping-patterns` induced memory-blowup
by GHC 04 Feb '16

04 Feb '16

#11374: `-Woverlapping-patterns` induced memory-blowup -------------------------------------+------------------------------------- Reporter: hvr | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm afraid I've found yet another case that still let's the pattern checker go crazy (courtesy of hackage:cryptol-2.2.5): {{{#!hs {-# LANGUAGE Haskell2010 #-} {-# OPTIONS_GHC -Woverlapping-patterns #-} module Bug where data Type = TCon TCon [Type] | TUser String [Type] Type | TRec [(String,Type)] deriving (Show,Eq,Ord) data TCon = TC TC | TF TFun deriving (Show,Eq,Ord) data TC = TCNum Integer | TCInf | TCBit | TCSeq | TCFun | TCTuple Int deriving (Show,Eq,Ord) data TFun = TCAdd | TCSub | TCMul | TCDiv | TCMod | TCLg2 | TCExp | TCWidth | TCMin | TCMax | TCLenFromThen | TCLenFromThenTo deriving (Show, Eq, Ord, Bounded, Enum) simpFinTy :: Type -> Maybe [Type] simpFinTy ty = case ty of TCon (TC (TCNum _)) _ -> Just [] TCon (TF tf) [t1] | TCLg2 <- tf -> Just [t1] | TCWidth <- tf -> Just [t1] TCon (TF tf) [t1,t2] | TCAdd <- tf -> Just [t1, t2] | TCSub <- tf -> Just [t1] | TCMul <- tf -> Just [t1, t2] | TCDiv <- tf -> Just [t1] | TCMod <- tf -> Just [] | TCExp <- tf -> Just [t1, t2] | TCMin <- tf -> Nothing | TCMax <- tf -> Just [t1, t2] TCon (TF tf) [_,_,_] | TCLenFromThen <- tf -> Just [] | TCLenFromThenTo <- tf -> Just [] _ -> Nothing }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11374> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11276: GHC hangs/takes an exponential amount of time with simple program
by GHC 04 Feb '16

04 Feb '16

#11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This was discovered when trying to compile xml-conduit. Here is the standalone test case with a few comments indicating how to make it compile. The program compiles with ghc-7.10.2 but fails with HEAD. {{{#!hs {-# LANGUAGE RankNTypes #-} module Hang where import Control.Monad import Data.Char data Event = EventBeginDocument | EventEndDocument | EventBeginDoctype | EventEndDoctype | EventInstruction | EventBeginElement | EventEndElement | EventContent Content | EventComment | EventCDATA data Content = ContentText String | ContentEntity String peek :: Monad m => Consumer a m (Maybe a) peek = undefined type Consumer i m r = forall o. ConduitM i o m r tag :: forall m a b c o . Monad m => ConduitM Event o m (Maybe c) tag = do _ <- dropWS return undefined where -- Add this and it works -- dropWS :: Monad m => ConduitM Event o m (Maybe Event) dropWS = do -- Swap these two lines and it works -- let x = undefined x <- peek let isWS = case x of -- Remove some of these and it works Just EventBeginDocument -> True Just EventEndDocument -> True Just EventBeginDoctype{} -> True Just EventEndDoctype -> True Just EventInstruction{} -> True Just EventBeginElement{} -> False Just EventEndElement{} -> False Just (EventContent (ContentText t)) | all isSpace t -> True | otherwise -> False Just (EventContent ContentEntity{}) -> False Just EventComment{} -> True Just EventCDATA{} -> False Nothing -> False if isWS then dropWS else return x -- Inlined Instances instance Functor (ConduitM i o m) where fmap f (ConduitM c) = ConduitM $ \rest -> c (rest . f) instance Applicative (ConduitM i o m) where pure x = ConduitM ($ x) {-# INLINE pure #-} (<*>) = ap {-# INLINE (<*>) #-} instance Monad (ConduitM i o m) where return = pure ConduitM f >>= g = ConduitM $ \h -> f $ \a -> unConduitM (g a) h instance Monad m => Functor (Pipe l i o u m) where fmap = liftM {-# INLINE fmap #-} instance Monad m => Applicative (Pipe l i o u m) where pure = Done {-# INLINE pure #-} (<*>) = ap {-# INLINE (<*>) #-} instance Monad m => Monad (Pipe l i o u m) where return = pure {-# INLINE return #-} HaveOutput p c o >>= fp = HaveOutput (p >>= fp) c o NeedInput p c >>= fp = NeedInput (p >=> fp) (c >=> fp) Done x >>= fp = fp x PipeM mp >>= fp = PipeM ((>>= fp) `liftM` mp) Leftover p i >>= fp = Leftover (p >>= fp) i newtype ConduitM i o m r = ConduitM { unConduitM :: forall b. (r -> Pipe i i o () m b) -> Pipe i i o () m b } data Pipe l i o u m r = HaveOutput (Pipe l i o u m r) (m ()) o | NeedInput (i -> Pipe l i o u m r) (u -> Pipe l i o u m r) | Done r | PipeM (m (Pipe l i o u m r)) | Leftover (Pipe l i o u m r) l }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20