December 2018 - ghc-tickets

[GHC] #15866: libiserv's version number is hard-coded
by GHC 07 Dec '18

07 Dec '18

#15866: libiserv's version number is hard-coded -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I recently discovered that GHC 8.6.2 was shipped with `libiserv-8.6.1`. Yes, you read that correctly—8.6.1, not 8.6.2. I was baffled at how this could possibly happen until I realized that we hard-code the version number for `libiserv` directly in its `.cabal` file. Needless to say, this is quite easy to forget to update. Let's let `autoconf` do the hard work for us and use `@ProjectVersionMunged@` instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15866> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15996: Add Unlifted List type to base
by GHC 07 Dec '18

07 Dec '18

#15996: Add Unlifted List type to base -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: | Version: 8.6.2 libraries/base | 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 data UList (a :: TYPE 'UnliftedRep) where UNil :: UList a UCons :: a -> UList a -> UList a }}} This would guarantee that values stored inside the list would not be thunks. It would likely live in something like GHC.List.Unlifted, since it uses GHC-specific things. An example of something it might improve is the implementation of Control.Concurrent.QSem.QSem: {{{#!hs data QSem = QSem !(MVar (Int, [MVar ()], [MVar ()])) }}} this could instead be: {{{#!hs type MVarIO = MVar# RealWorld -- type synonym for brevity data QSem = QSem (MVarIO (Int, UList (MVarIO ()), UList (MVarIO ()))) }}} Note that in this example the tuple inside the outermost `MVarIO` boxes the `Int` - this tuple could be represented as a datatype which ensures the unboxing on the `Int`. The main idea here though is that now you can use `MVar#` inside of the `UList`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15996> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15998: GHC.Event.Thread.eventManager has a lot of indirections
by GHC 07 Dec '18

07 Dec '18

#15998: GHC.Event.Thread.eventManager has a lot of indirections -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: | Version: 8.6.2 libraries/base | 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: -------------------------------------+------------------------------------- Current `eventManager`: {{{#!hs eventManager :: IORef (IOArray Int (Maybe (ThreadId, EventManager))) eventManager = unsafePerformIO $ do ... }}} That's a lot of indirections just to grab your thread's event manager. Consider the following, which I believe would improve the performance of this: {{{#!hs data UnliftedIORef :: TYPE 'UnliftedRep -> Type where UnliftedIORef :: MutVar# RealWorld a -> UnliftedIORef a eventManager :: UnliftedIORef (MutableArray# RealWorld Things) data Things = Things !ThreadId !EventManager }}} I think the Maybe can be eliminated. I'm unsure. What makes me think it can be is the following snippet: {{{#!hs getSystemEventManager :: IO (Maybe EventManager) getSystemEventManager = do t <- myThreadId (cap, _) <- threadCapability t eventManagerArray <- readIORef eventManager mmgr <- readIOArray eventManagerArray cap return $ fmap snd mmgr getSystemEventManager_ :: IO EventManager getSystemEventManager_ = do Just mgr <- getSystemEventManager return mgr {-# INLINE getSystemEventManager_ #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15998> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15780: ghc-8.4.4 failed to build on armv7 and aarch64
by GHC 07 Dec '18

07 Dec '18

#15780: ghc-8.4.4 failed to build on armv7 and aarch64 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc-8.4.4 is failing to build for me on Fedora ARM archs (both 32bit and 64bit). https://koji.fedoraproject.org/koji/taskinfo?taskID=30284522 They both fail in the same way: {{{ "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgMiscClosures.cmm -o rts/dist/build/StgMiscClosures.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.4.4 for aarch64-unknown-linux): padLiveArgs -- i > regNum ?? CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen/Base.hs:194:27 in ghc:LlvmCodeGen.Base Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [rts/ghc.mk:295: rts/dist/build/HeapStackCheck.o] Error 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15780> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13104: runRW# ruins join points
by GHC 07 Dec '18

07 Dec '18

#13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Found this while poking around in the example for #12781. Suppose we have code like this: {{{ let loop :: Int -> State# RealWorld -> (State# RealWorld, Int) loop n = ... loop (n+1) {- tail call -} ... in runRW# @ 'PtrRepLifted @ Int (loop 0) }}} We would love for `loop` to be a join point, but it can't be because it's invoked in the argument to `runRW#`. In this situation, we're often rescued by Float In, which we might hope to give us this: {{{ runRW# @ 'PtrRepLifted @ Int ( let loop :: Int -> State# RealWorld -> (State# RealWorld, Int) loop n s = ... loop (n+1) s' {- tail call -} ... in loop 0 ) }}} Two problems: 1. Float In won't do this to begin with because `loop 0` is a partial application. 2. It's still not eligible to be a join point, again because `loop 0` is a partial application. What we would //like// to see is this: {{{ runRW# @ 'PtrRepLifted @ Int ( \s0 -> let loop :: Int -> State# RealWorld -> (State# RealWorld, Int) loop n s = ... loop (n+1) s' {- tail call -} ... in loop 0 s0 ) }}} Now we're golden. But someone has to have thought to eta-expand the argument to `runRW#` first. (Float In should then float `loop` into the lambda because, due to the state hack, the lambda is considered one-shot.) Perhaps the simplifier should //always// eta-expand the argument to `runRW#`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13104> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #14847: Inferring dependent kinds for non-recursive types
by GHC 06 Dec '18

06 Dec '18

#14847: Inferring dependent kinds for non-recursive types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this {{{ data Proxy k (a :: k) = MkProxy data Proxy2 k a = MkP (Proxy k a) }}} which is discussed in [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#inferring-dependency-in-datatype-declarations a corner of the user manual]. Surprisingly, we reject `Proxy2` -- but there is nothing difficult about inferring its kind. There would be if it was recursive -- but it isn't. Simple solution: for non-recursive type declarations (we do SCC analysis so we know which these are) do not call `getInitialKinds`; instead, just infer the kind of the definition! Simple. Warning: is this recursive? {{{ data Proxy2 k a where MkP :: Proxy k a -> Proxy2 k a }}} Presumably no more than the other definition. But currently we need `Proxy2` in the environment during kind inference, because we kind-check the result type. That seems jolly odd and inconsistent. Needs more thought. Similar questions for {{{ data T a where T :: Int -> T Bool type family F a where F Int = True F _ = False }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14847> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12088: Promote data family instance constructors
by GHC 06 Dec '18

06 Dec '18

#12088: Promote data family instance constructors -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #11348 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In `TcEnv.hs` there is a note AFamDataCon: not promoting data family constructors. It states that we can't use a promoted data family instance constructor because we would have to interleave the checking of instances and data types. But with the fix of #11348, we now do exactly this. In the example from the note {{{#!hs data family T a data instance T Int = MkT data Proxy (a :: k) data S = MkS (Proxy 'MkT) }}} -ddump-rn-trace shows these groups {{{ rnTycl dependency analysis made groups [[data family T a_apG] [] [data instance T Int = MkT], [data Proxy (a_apF :: k_apE)] [] [], [data S = MkS (Proxy MkT)] [] []] }}} That's to say, the instance `T Int` will in fact be checked before `S`. So let's remove this restriction. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12088> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 53

Re: [GHC] #7503: Bug with PolyKinds, type synonyms & GADTs
by GHC 06 Dec '18

06 Dec '18

#7503: Bug with PolyKinds, type synonyms & GADTs -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.1 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T7503a Blocked By: | Blocking: Related Tickets: #14451, #12088 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by simonpj): * related: #14451 => #14451, #12088 Comment: #12088 seems to be in the same territory -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7503#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15989: Adding extra quantified constraints leads to resolution failure
by GHC 06 Dec '18

06 Dec '18

#15989: Adding extra quantified constraints leads to resolution failure -------------------------------------+------------------------------------- Reporter: eror | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 (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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE QuantifiedConstraints, FlexibleContexts #-} import Control.Monad.Reader data T x = T { anX :: x, anInt :: Int } ok :: ( forall x x'. MonadReader (T x) (m x') ) => m y Bool ok = fmap not (pure True) bad :: ( forall x x'. MonadReader (T x) (m x') , forall x. Monad (m x) ) => m y Bool bad = fmap not (pure True) better :: ( forall x x'. MonadReader (T x) (m x') , forall x. Applicative (m x) , forall x. Functor (m x) ) => m y Bool better = fmap not (pure True) }}} `ok` and `better` compile, but `bad` fail to resolve, despite having strictly more in the context than `ok`: {{{ BadQC.hs:15:7: error: • Could not deduce (Functor (m y)) arising from a use of ‘fmap’ from the context: (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) bound by the type signature for: bad :: forall (m :: * -> * -> *) y. (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) => m y Bool at BadQC.hs:(12,1)-(14,15) • In the expression: fmap not (pure True) In an equation for ‘bad’: bad = fmap not (pure True) | 15 | bad = fmap not (pure True) | ^^^^^^^^^^^^^^^^^^^^ BadQC.hs:15:17: error: • Could not deduce (Applicative (m y)) arising from a use of ‘pure’ from the context: (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) bound by the type signature for: bad :: forall (m :: * -> * -> *) y. (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) => m y Bool at BadQC.hs:(12,1)-(14,15) • In the second argument of ‘fmap’, namely ‘(pure True)’ In the expression: fmap not (pure True) In an equation for ‘bad’: bad = fmap not (pure True) | 15 | bad = fmap not (pure True) | ^^^^^^^^^ Failed, no modules loaded. }}} Also: * `( forall x. MonadReader (T x) (m x), forall x. Monad (m x) )` compiles — the error seems to require two quantified type variables * `( forall x x'. Monad (m x), forall x. Monad (m x) )` reports an ambiguity error on the constraint, which makes sense; if I turn on `AllowAmbiguousTypes`, it fails with the same error as above — the error isn't caused by MPTCs, and it doesn't matter that `x'` is unused * `( forall x x'. Foldable (m x), forall x. Monad (m x) )` and `( forall x x'. Monad (m x), forall x. Foldable (m x) )` compile — being in the same class hierarchy matters * `( forall x x'. Applicative (m x), forall x. Monad (m x) )` fails on `fmap` (but not `pure`) — which is the superclass doesn't seem to matter -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15989> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14727: Unboxed sum performance surprisingly poor
by GHC 06 Dec '18

06 Dec '18

#14727: Unboxed sum performance surprisingly poor -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: UnboxedSums | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tried performing worker-wrapper manually on `Data.IntMap.lookup`: {{{#!hs lookup# :: Int -> IntMap a -> (# (# #) | a #) lookup# = -- The obvious modification of the current implementation lookup :: Int -> IntMap a -> Maybe a lookup k m = case lookup# k m of (# | a #) -> Just a _ -> Nothing }}} Unfortunately, the `lookup` benchmark ''slowed down''. I verified that the benchmark indeed performs an immediate case analysis on the result (with `fromMaybe`), so it ''should'' go faster. And yet it goes slower. Caveat: I have not yet gotten things set up to be able to check with 8.4, so if there have been improvements in `UnboxedSum` performance since `8.2.2`, this may all be silly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14727> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6