October 2018 - ghc-tickets

[GHC] #13573: Add Foldable1 / Traversable1 to base
by GHC 26 Nov '18

26 Nov '18

#13573: Add Foldable1 / Traversable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | 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: #10365 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `NonEmpty` and `Semigroup` are in ''base'' and are on our way to add `Semigroup` as a superclass of `Monoid` (#10365), this is a fine time to ask if we should include [https://hackage.haskell.org/package/semigroupoids-5.1/docs/Data- Semigroup-Foldable.html Foldable1], [https://hackage.haskell.org/package/semigroupoids-5.1/docs/Data- Semigroup-Traversable.html Traversable1] in ''base'' as well. `Foldable` has partial functions already, functions that only make sense for non-empty structures such as `foldr1`, `foldl1`, `minimum` and `maximum`. There are also functions which ''could'' be defined in terms of `Foldable` like `head` / `tail` (for definition of `unimprove` and `Diff` see [https://github.com/ekmett/semigroupoids/issues/49 semigroupoids issue #49] and this [https://github.com/arkeet/difference/blob/0f0e14f51cf1ecd7ebf2d8c52204bd91a… github] page) {{{#!hs minimum1 :: (Ord a, Foldable1 f) => f a -> a minimum1 = S.getMin . foldMap1 S.Min maximum1 :: (Ord a, Foldable1 f) => f a -> a maximum1 = S.getMax . foldMap1 S.Max head1 :: Foldable1 f => f a -> a head1 = S.getFirst . foldMap1 S.First last1 :: Foldable1 f => f a -> a last1 = S.getLast . foldMap1 S.Last foldr1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldr1 f = unimprove . foldMap1 (\a -> Diff (f a) a) foldl1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldl1 f = unimprove . getDual . foldMap1 (\a -> Dual $ Diff (flip f a) a) }}} There is also the possibility of adding further functions such as `foldM`, `foldM_`, `foldrM` and `foldlM` for non-empty structures. As usual I don't have more concrete ideas, but let's start by testing the waters before submitting a ghc-proposal. I understand this may be controversial -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13573> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #13362: GHC first generation of GC to be as large as largest cache size by default
by GHC 26 Nov '18

26 Nov '18

#13362: GHC first generation of GC to be as large as largest cache size by default -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System | Keywords: numa cache gc | 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 will improve performance a lot by default. If anyone needs different size - there is "-A" RTS option. Machines are very different. Currently this size is 512k by default for all different architectures and hardware no matter what. In most cases machines with larger caches have more RAM as well and vice versa. So this will affect positively both small and larger machines. It will be most efficient in most cases to keep short lived objects in caches. Most modern workstation and server machines have L3 cache as well, that is why I'm asking for "largest cache size". Second idea will be if there are two short lived generations on machines with second and third level caches with sizes that match both. For NUMA machines with non-unified caches (like [http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825 this strange and non-common ARM]) the common solution could be to set first generation to be with size of the largest cache of smallest core. Which will not be the optimal, but close to. [https://www.reddit.com/r/haskell/comments/5rf1r5/ghc_first_generation_of_gc… Related Reddit discussion] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13362> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #10844: CallStack should not be inlined
by GHC 26 Nov '18

26 Nov '18

#10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The use of CallStack based error messages (since changeset:6740d70d95cb) has led to some code size increase, and I believe this needs to be improved. While investigating the #10788, I was looking at the core produced by that code, and I found this in the code: {{{ -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main17 :: [Char] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 100 0}] Main.main17 = unpackCString# "vecto_20t0fI93Jj9LUbaZg6e04I"# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main16 :: [Char] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 110 0}] Main.main16 = unpackCString# "Data.Vector.Primitive.Mutable"# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main15 :: [Char] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 120 0}] Main.main15 = unpackCString# "./Data/Vector/Primitive/Mutable.hs"# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main14 :: Int [GblId, Caf=NoCafRefs, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] Main.main14 = I# 97# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main13 :: Int [GblId, Caf=NoCafRefs, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] Main.main13 = I# 16# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main12 :: Int [GblId, Caf=NoCafRefs, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] Main.main12 = I# 21# -- RHS size: {terms: 8, types: 0, coercions: 0} Main.main11 :: SrcLoc [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 80}] Main.main11 = SrcLoc Main.main17 Main.main16 Main.main15 Main.main14 Main.main13 Main.main14 Main.main12 }}} This is clearly a CallStack from a library, and there is no point in copying that into the (every?) use of wherever that came from, as it will only increase code size and slow down compilation. I don’t know how to fix it, though. Float out CallStacks more aggressively? Or is the problem that unfoldings are recorded before that can happen? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10844> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #10803: New TypeSignatureSections extension
by GHC 26 Nov '18

26 Nov '18

#10803: New TypeSignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- = Preliminary specification Have - `(::` ''type'' `)` be syntax sugar for - `(\x -> x ::` ''type'' `)` This new syntax extension is enabled via a new `TypeSignatureSections` language pragma, i.e. {{{#!hs {#- LANGUAGE TypeSignatureSections #-} }}} TODO: formalise this a bit more -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10803> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times)
by GHC 26 Nov '18

26 Nov '18

#15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Load the following code into GHCi HEAD (8.7+): {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Kind type family F1 a type instance forall a. F1 a = Maybe a type family F2 a where forall a. F2 a = Maybe a data family D a data instance forall a. D a = MkD (Maybe a) }}} And make sure you have the `-fprint-explicit-foralls` flag enabled. Now let's see what happens when we look up the `:info` for each of these type families: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs -fprint- explicit-foralls GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, one module loaded. λ> :i F1 type family F1 a :: * -- Defined at Bug.hs:7:1 type instance F1 a = Maybe a -- Defined at Bug.hs:8:25 λ> :i F2 type family F2 a :: * where [a] F2 a = Maybe a -- Defined at Bug.hs:10:1 λ> :i D data family D a -- Defined at Bug.hs:13:1 data instance D a = MkD (Maybe a) -- Defined at Bug.hs:14:25 }}} There are two strange things of note here: * The equations for `F1` and `D` do not have any explicit `forall`s displayed at all, despite the fact that `-fprint-explicit-foralls` is enabled. * The equation for `F2` //does// have an explicit `forall` displayed, but in a rather bizarre fashion: {{{ λ> :i F2 type family F2 a :: * where [a] F2 a = Maybe a -- Defined at Bug.hs:10:1 }}} I certainly wasn't expecting to see the type variables in square brackets. I would have hoped to see something like this instead: {{{ λ> :i F2 type family F2 a :: * where forall a. F2 a = Maybe a -- Defined at Bug.hs:10:1 }}} Now that the "more explicit `forall`s" proposal is implemented, my hope is that it will be somewhat simple to change the way that this is pretty- printed (we already store the explicit `forall` information within the AST, after all). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15827> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15241: T2783 fails a sanity test
by GHC 26 Nov '18

26 Nov '18

#15241: T2783 fails a sanity test -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.4.3 System | 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: -------------------------------------+------------------------------------- {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.2 $ ghc test.hs -fforce-recomp -debug -rtsopts [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... $ ./test +RTS -DS test: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314 Stack trace: test: Failed to get stack frames of current process: no matching address range: Success 0x4a3fbd set_initial_registers (rts/Libdw.c:288.0) 0x7f9d70fd7a18 dwfl_thread_getframes (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x7f9d70fd7efc dwfl_getthread_frames (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x4a3eb6 libdwGetBacktrace (rts/Libdw.c:257.0) 0x474de3 rtsFatalInternalErrorFn (rts/RtsMessages.c:171.0) 0x474ad0 barf (rts/RtsMessages.c:48.0) 0x474b02 errorBelch (rts/RtsMessages.c:67.0) 0x479273 threadPaused (rts/ThreadPaused.c:318.0) 0x48ccdb stg_returnToSched (rts/StgStartup.cmm:117.1) 0x48f428 stg_enter_info (rts/HeapStackCheck.cmm:166.1) 0x45fd18 integerzmgmp_GHCziIntegerziType_minusInteger_info (/home/omer/haskell/test) (GHC version 8.4.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./test +RTS -DS }}} Note tested with HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15241> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #12232: Opportunity to do better in register allocations
by GHC 25 Nov '18

25 Nov '18

#12232: Opportunity to do better in register allocations -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (NCG) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #12231 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://github.com/harendra-kumar/unicode-transforms/tree/GHC_PERF_ISSUE This github repo] demonstrates that introduction of one "if" condition which is never taken, degrades the performance of the fast path loop in this particular use case by around 70%, from 2.6ms to 4.4 ms. On investigation I found two main issues. See #12231(ticket) regarding rdeundant allocations. This one is about the other issue regarding register allocations. [https://github.com/harendra-kumar/unicode- transforms/commit/261dbb35e753376e4ee160dab556051738a0be50#diff- 4be4240cb00d1b13a038d1d45fbae235 See this assembly diff] of instructions executed in both cases. The repo has both versions to play with and simpl/stg/cmm/asm are checked in. The first file in the diff is with the if condition and the second one without. To summarize, the introduction of "if" condition adds the following register manipulations before and after the main logic: {{{ # reassignments # rbx -> r10 -> r9 -> r8 -> rdi -> rsi -> rdx -> rcx -> rbx => 0x408d7e: mov %rbx,0x90(%rsp) => 0x408d86: mov %rcx,%rbx => 0x408d89: mov %rdx,%rcx => 0x408d8c: mov %rsi,%rdx => 0x408d8f: mov %rdi,%rsi => 0x408d92: mov %r8,%rdi => 0x408d95: mov %r9,%r8 => 0x408d98: mov %r10,%r9 => 0x408d9b: mov 0x90(%rsp),%r10 . . . loop logic here which uses only %rax, %r10 and %r9 . . . . # _n4s8: # shuffle back to original assignments => 0x4090dc: mov %r14,%r11 => 0x4090df: mov %r9,%r10 => 0x4090e2: mov %r8,%r9 => 0x4090e5: mov %rdi,%r8 => 0x4090e8: mov %rsi,%rdi => 0x4090eb: mov %rdx,%rsi => 0x4090ee: mov %rcx,%rdx => 0x4090f1: mov %rbx,%rcx => 0x4090f4: mov %rax,%rbx => 0x4090f7: mov 0x88(%rsp),%rax => 0x4090ff: jmpq 0x408d2a }}} The registers seem to be getting reassigned here, data flowing from one to the next. In this particular path a lot of these register movements seem unnecessary and are only undone at the end without being used. My suspicion is that this allocation is being done en bloc keeping several paths in mind, just like the heap allocations I reported in the other issue. Some questions to be answered: * Can we make this smarter? * Will `-fregs-graph` do a better job and if not what improvements can be done to graph coloring allocator to do a good job here? I have try that option yet. LLVM assembly trace is also available in the repo. == References == * [1] mail thread: https://mail.haskell.org/pipermail/ghc- devs/2016-June/012243.html * [2] github code repo: https://github.com/harendra-kumar/unicode- transforms/tree/GHC_PERF_ISSUE -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12232> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13262: Allow type synonym family application in instance head if it reduces away
by GHC 25 Nov '18

25 Nov '18

#13262: Allow type synonym family application in instance head if it reduces away -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- GHC rejects the following program: {{{ {-# LANGUAGE TypeFamilies, FlexibleInstances #-} module F where type family F a type instance F Int = Int -> Int instance Show (F Int) where show _ = "fun" }}} But this doesn't seem fundamentally problematic to me: at the instance declaration, we know that F Int will reduce, and after that reduction there isn't any problem with the instance. Here's a less restrictive instance head test: first, we reduce type families as much as possible. Then, if there are still leftover non- reducing type families, reject the instance. After having typed this up, I have realized that I don't actually need this feature. But I'm filing it here for posterity. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13262> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15810: Kind inference error in classes
by GHC 25 Nov '18

25 Nov '18

#15810: Kind inference error in classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- This is rejected today, but it shouldn't be: {{{#!hs class C a where meth :: Proxy (a :: k) }}} It's the kind signature that kills it. Expected solution: change `tcImplicitTKBndrs` to `kcImplicitTKBndrs` in `kcHsKindSig`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15810> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14690: Pattern match failure in GHCi with :steplocal
by GHC 25 Nov '18

25 Nov '18

#14690: Pattern match failure in GHCi with :steplocal --------------------------------------+--------------------------------- Reporter: Philonous | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Using steplocal after breaking on an exception leads to GHCI giving a pattern match error Minimal testcase: {{{ Prelude> :set -fbreak-on-exception Prelude> error "abc" Stopped in <exception thrown>, <unknown> _exception :: e = _ [<unknown>] [<unknown>] Prelude> :steplocal *** Exception: Pattern match failure in do expression at ghc/GHCi/UI.hs:3149:12-18 }}} :step works as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14690> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3