July 2017 - ghc-tickets

[GHC] #13283: T5435_dyn_asm fails with gold linker
by GHC 31 Jul '17

31 Jul '17

#13283: T5435_dyn_asm fails with gold linker -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.1 System (Linker) | 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 tried validating with `ld.gold` as my system linker and one test failed: {{{ cd "./rts/T5435_dyn_asm.run" && $MAKE -s --no-print-directory T5435_dyn_asm T5435_dyn_asm failed with ['initArray1', 'initArray2', 'ctors2', 'ctors1', 'success'], see all.T for details }}} The expected output has `ctors1` and then `ctors2`. This looks like a bug in gold to me. ezyang, do you agree? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13283> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13744: Compile-time regression in 8.2 when compiling bloodhound's test suite
by GHC 31 Jul '17

31 Jul '17

#13744: Compile-time regression in 8.2 when compiling bloodhound's test suite -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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: -------------------------------------+------------------------------------- GHC 8.2 takes much longer to compile bloodhound's test suite than GHC 8.0.2. With 8.0.2, compilation takes approximately a minute on my machine, 8.2 takes approximately four minutes and uses much more memory. How to reproduce: {{{ $ git clone -b ghc-8.2 https://github.com/23Skidoo/bloodhound.git $ cd bloodhound $ cabal new-build -w ghc-8.0.1 --enable-tests $ cabal new-build -w ghc-8.2.1 --enable-tests }}} GHC version: {{{ $ ghc-8.2.1 --version The Glorious Glasgow Haskell Compilation System, version 8.2.0.20170505 }}} These warnings (fixed in my `ghc-8.2` branch of `bloodhound`) may provide a clue to what's happening: {{{ tests/V1/tests.hs:1876:17: warning: [-Wsimplifiable-class-constraints] • The constraint ‘SOP.All SOP.SListI (SOP.GCode a)’ matches an instance declaration instance forall k (f :: k -> Constraint) (xs :: [k]). (Generics.SOP.Constraint.AllF f xs, SOP.SListI xs) => SOP.All f xs -- Defined in ‘Generics.SOP.Constraint’ This makes type inference for inner bindings fragile; either use MonoLocalBinds, or simplify it using the instance • In the type signature: sopArbitrary :: forall a. (Generic a, SOP.GTo a, SOP.All SOP.SListI (SOP.GCode a), SOP.All2 Arbitrary (SOP.GCode a)) => Gen a }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13817: Simplifier and SpecConstr performance regression with 8.2.1
by GHC 31 Jul '17

31 Jul '17

#13817: Simplifier and SpecConstr performance regression with 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A propietary application I've upgraded to compile with 8.2.1-rc1 makes GHC manifest a performance regression when producing optimized ({{{-O2}}}) code. After a crude analysis of a compile log produced with {{{-show-passes}}} it appears that the biggest slowdown is in the Simplifier and SpecConstr phases when compiling the "main" modules. Theres a conversation at GHC Users with more details: https://mail.haskell.org/pipermail/glasgow-haskell- users/2017-June/026543.html. The data, the results and the script to to analyse it live at: https://gist.github.com/albertov/145ac5c01bfbadc5c9ff55e9c5c2e50e I'll try to update this ticket with a way to to reproduce it as soon as I can (if I can) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13817> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9020: Massive blowup of code size on trivial program
by GHC 31 Jul '17

31 Jul '17

#9020: Massive blowup of code size on trivial program ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The test `simplCore/should_compile/simpl015` was leading to massive compile times. This is weird: it looks like: {{{ main = do { return () ; return () ... hundreds more times ... ; return () } }}} It turns out that the cause was over-eager eta-expansion. Each `return ()` gives a top-level PAP thus {{{ lvl17 :: IO () lvl17 = returnIO () }}} But these definitions are then eta-expanded, thus: {{{ lvl17 = ((\eta. returnIO () |> sym g) eta) |> g where g :: State# RealWorld -> (# State# RealWorld, () #) ~ IO () }}} Now in general it makes sense to eta-expand through newtypes (as is done here), because it exposes more lambadas. But it really doesn't make sense to eta-expand a PAP like this. Fortunately the fix is easy: use `exprArity` rather than `manifestArity` in `SimplUtils.tryEtaExpandRhs`. The effect on `simpl015` is dramatic: compiler allocation drops from 6.6G to 812M; and residency drops from 1.8G to 45M. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9020> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2
by GHC 31 Jul '17

31 Jul '17

#13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Try running this code in GHCi: {{{ λ> :set -XBangPatterns -XRankNTypes -XTypeFamilies λ> let x :: forall a . a ~ Integer => forall b. b ~ Integer => (a, b); !x = (1, 2) }}} In GHC 8.0.1 and 8.0.2, this works. But in GHC 8.2.1: {{{ <interactive>:3:74: Couldn't match expected type ‘forall a. (a ~ Integer) => forall b. (b ~ Integer) => (a, b)’ with actual type ‘(Integer, Integer)’ In the expression: (1, 2) In a pattern binding: !x = (1, 2) }}} If you put this code into a source file: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} module Bug where x :: forall a . a ~ Integer => forall b. b ~ Integer => (a, b) !x = (1, 2) }}} Then it also works in GHC 8.0.1. and 8.0.2, but it errors on GHC 8.2 (this time with a different error): {{{ GHCi, version 8.2.0.20170413: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:6:1: error: Overloaded signature conflicts with monomorphism restriction x :: forall a. a ~ Integer => forall b. b ~ Integer => (a, b) | 6 | x :: forall a . a ~ Integer => forall b. b ~ Integer => (a, b) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13594> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #14035: Weird performance results.
by GHC 31 Jul '17

31 Jul '17

#14035: Weird performance results. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Hi! I was recently testing performance of a critical code in a product we are shipping and I'm getting really weird results. The first "part" of it I've described here: https://ghc.haskell.org/trac/ghc/ticket/14013 (and I will be referring to this issue later), however there are some other problems that do not seem directly connected to 14013 ticket. **The code is compiled with `-XStrict` enabled globally. The full source code for this ticket is attached.** The code is a pseudo-parser implementation. It consumes any char in a loop and fails on empty input in the end. \\ == Helpers Let's define 2 helpers: {{{#!hs (.) :: (b -> c) -> (a -> b) -> a -> c (.) f g = \x -> f (g x) ; {-# INLINE (.) #-} dotl :: (b -> c) -> (a -> b) -> a -> c dotl ~f ~g = \ ~x -> f (g x) ; {-# INLINE dotl #-} }}} So whenever we see `.` in code it is strict in all of its arguments. \\ == Strict StateT performance improvement Let's consider following code: {{{#!hs import qualified Control.Monad.State.Strict as S newtype StateT s m a = StateT { fromStateT :: S.StateT s m a } deriving (Applicative, Functor, Monad, MonadTrans) class MonadState s m | m -> s where get :: m s put :: s -> m () runStateT :: forall s m a. StateT s m a -> s -> m (a, s) evalStateT :: forall s m a. Functor m => StateT s m a -> s -> m a runStateT m s = S.runStateT (fromStateT m) s ; {-# INLINE runStateT #-} evalStateT m = fmap fst . runStateT m ; {-# INLINE evalStateT #-} instance Monad m => MonadState s (StateT s m) where get = StateT S.get ; {-# INLINE get #-} put = StateT . S.put ; {-# INLINE put #-} }}} There are few non-obvious things to note here: 1. This wrapper performs about **15 TIMES better** than `Control.Monad.State.Strict.StateT` (in the provided examples) and if we create a loop in pure code imitating a parser, this `StateT` gets completely optimized away, while the `mtl`'s version does not. 2. If we replace the following functions with lazy composition, we get the same, high performance: {{{#!hs runStateT = S.runStateT `dotl` fromStateT ; {-# INLINE runStateT #-} evalStateT m = fmap fst `dotl` runStateT m ; {-# INLINE evalStateT #-} }}} 3. However, if we slightly change the `evalStateT`, we've got the bad performance, equals to the `mtl`'s `StateT` version (15 times slower): {{{#!hs evalStateT m a = fmap fst $ runStateT m a ; {-# INLINE evalStateT #-} }}} It's a very strange result, especially that `evalStateT` is used only once in the code while running the tests. \\ == Strict Either & EitherT The code contains a very minimalistic implementation of `Either` and `EitherT` in order to make their definitions and utils strict. These definitions are copy-pasted and simplified (removed unused code) from: https://hackage.haskell.org/package/base-4.10.0.0/docs/src/Data.Either.html https://hackage.haskell.org/package/either-4.4.1.1/docs/src/Control.Monad.T… \\ == Strict Bool and tuple Moreover we define strict Bool `or` operation and 2-element tuple with strict arguments: {{{#!hs data T a b = T !a !b deriving (Generic, Show, Functor) data XBool = XTrue | XFalse deriving (Show, Generic) (|||) :: XBool -> XBool -> XBool (|||) !a !b = case a of XTrue -> a XFalse -> b {-# INLINE (|||) #-} }}} \\ == Parser implementation All the above declarations were simple helpers compiled with `-XStrict`, because available libraries do not provide them for us. This code is a "real" use case and shows the weird performance results. The parser implementation is simple: {{{#!hs newtype FailParser m a = FailParser { fromFailParser :: EitherT () m (T XBool a) } deriving (Functor) instance Monad m => Applicative (FailParser m) where pure = undefined (<*>) = undefined instance Monad m => Monad (FailParser m) where return a = FailParser $ pure $ (T XFalse a) ; {-# INLINE return #-} FailParser ma >>= f = FailParser $ do T !b a <- ma T !b' a' <- fromFailParser $ f a return $! T (b ||| b') a' {-# INLINE (>>=) #-} _ >> _ = undefined ; {-# INLINE (>>) #-} instance MonadTrans (FailParser) where lift m = FailParser $! lift $ fmap (T XFalse) m ; {-# INLINE lift #-} }}} We use `undefined` for non-important functions. The parser is `EitherT` wrapper: Left happens when we failed parsing input, while Right otherwise. The `XBool` denotes if we made any progress (so after consuming a letter it is set to `XTrue`). There are some additional util functions, like `returnProgress` which behaves just like return, but also sets the `XBool` value to `XTrue`: {{{#!hs instance Monad m => MonadProgressParser (FailParser m) where returnProgress a = FailParser $! pure (T XFalse a) ; {-# INLINE returnProgress #-} -- In correct code it should be XTrue as described below. }}} In the provided code, there is `XFalse` used instead of `XTrue` because of some interesting observations: 1. The `XBool` value is used ONLY in the expression `return $! T (b ||| b') a'` above, so it does NOT affect the way the program logically executes it's body. 2. Both `b` and `b'` are strict and fully evaluated. 3. If both `b` and `b'` are `XFalse` (as in the provided code, they always are `XFalse`) we get a good performance. In order to test it, the above code contains `XFalse` instead of `XTrue`. 4. If we use the correct version of `returnProgress` as described just before point 1 above, we get 15 times slower performance (the same or very similar to the one when used altered `evalStateT` definition). We could try to explain it: maybe Haskell was able to optimize code if it discovered, there always were only `XFalse` values used and after the change there are both `XTrue` and `XFalse`, so it really has to run the `(|||)` operator. This way of thinking fails as fast as we check that changing `XFalse` to `XTrue` **everywhere** in the code give us again bad performance. 5. If we replace `return $! T (b ||| b') a'` with `return $! T b' a'` we get good performance, while replacing it with `return $! T b a'` give us bad performance. It does not make any sense, because both `b` and `b'` are strict and fully evaluated. Moreover, it is the only place in code where they are used. 6. However replacing `return $! T (b ||| b') a'` with `return $! T (b' ||| b) a'` does NOT change the performance (we are getting the good one). == Final notes We've been talking with some people - both in the company I'm working in as well as on IRC and we do not see any reason why this code behaves in this way and why it is so sensitive to the changes. In fact we started to be worried a lot about how we can use Haskell for high-performance parts at all if it is not obvious if a very simple changes do not affect performance so much, like changing `evalStateT m = fmap fst . runStateT m` to `evalStateT m a = fmap fst $ runStateT m a`, which gives 15 times slowdown. It makes the code both very fragile to any changes as well as makes it unmaintainable. Tracking performance in a very small program (like the attached one) is possible, while tracking it in bigger one, taking in considerating the described problems, make it almost impossible. I'm writing this because I'm worried about where these problems originate from and I would really like to solve them / know why they appear and be sure we can continue to use Haskell for our high-performance demanding applications. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14035> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #13054: Generating unique names with template haskell
by GHC 31 Jul '17

31 Jul '17

#13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | 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 need to use template haskell to generate a few instances where those instances each use a foreign function obtained from a particular {{{FunPtr}}}. As far as I'm aware, the only clean way to do this requires top level declarations of the form: {{{foreign import ccall "dynamic" makeFun1 :: FunPtr Foo -> Foo}}} If there was either: * Another way to do this without requiring top level named declarations. * The possibility to use these within a where clause (template haskell would suggest so given that it lets you use {{{Dec}}} within a {{{where}}}). Then I'd be fine probably be fine without names. I've tried using {{{newName}}} as it apparently generates fresh names but I cannot get it work for me. I've put a copy of the test case [https://gitlab.com/tim-m89/hs-th-name- issue here]. I compile with {{{stack build --ghc-options="-ddump-splices -ddump-to-file"}}} and the error is: {{{ th-name-issue/app/Main.hs:7:12: error: Multiple declarations of ‘makeFun’ Declared at: app/Main.hs:7:12 app/Main.hs:7:12 }}} Then I run {{{gvim .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/th- name-issue-exe/th-name-issue-exe-tmp/app/Main.dump-splices}}} And can see: {{{ app/Main.hs:7:12-25: Splicing declarations template-haskell-2.11.0.0:Language.Haskell.TH.Quote.quoteDec importGen " stuff here " ======> foreign import ccall safe "dynamic" makeFun_a3pc :: GHC.Ptr.FunPtr (Foreign.C.String.CString -> IO ()) -> Foreign.C.String.CString -> IO () foreign import ccall safe "dynamic" makeFun_a3pd :: GHC.Ptr.FunPtr (Foreign.C.String.CString -> IO ()) -> Foreign.C.String.CString -> IO () }}} Which suggests that I did manage to get unique names after all, so I don't know why it didn't compile?? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #14004: G
by GHC 31 Jul '17

31 Jul '17

#14004: G -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature | Status: new request | Priority: normal | 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} class GEq a b where geq :: a -> b -> Bool instance {-# OVERLAPPING #-} Eq a => GEq a a where geq = (==) instance GEq a b where geq _ _ = False }}} {{{ GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> :load GEq.hs [1 of 1] Compiling Main ( GEq.hs, interpreted ) Ok, modules loaded: Main. *Main> geq::a->b->Bool <interactive>:3:1: Overlapping instances for GEq a1 b1 arising from a use of ‘geq’ Matching instances: instance GEq a b -- Defined at GEq.hs:9:10 instance [overlapping] Eq a => GEq a a -- Defined at GEq.hs:6:30 (The choice depends on the instantiation of ‘a1, b1’ To pick the first instance above, use IncoherentInstances when compiling the other instance declarations) In the expression: geq :: a -> b -> Bool In an equation for ‘it’: it = geq :: a -> b -> Bool *Main> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14004> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

Re: [GHC] #7647: UNPACK polymorphic fields
by GHC 30 Jul '17

30 Jul '17

#7647: UNPACK polymorphic fields -------------------------------------+------------------------------------- Reporter: liyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3990 #9655 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by danilo2): * cc: danilo2 (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7647#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14055: Panic on type error inside a type-level newtype (with -XTypeInType)
by GHC 30 Jul '17

30 Jul '17

#14055: Panic on type error inside a type-level newtype (with -XTypeInType) -------------------------------------+------------------------------------- Reporter: luqui | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeInType, TypeFamilies #-} newtype X = RollX (() -> X) type family F t :: X where F t = RollX (t -> ()) }}} gives {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): repSplitAppTys t_a1po[sk:1] () [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:808:9 in ghc:Type }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14055> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4