January 2018 - ghc-tickets

[GHC] #14718: Add Boolean type families to 'base' package
by GHC 26 Jan '18

26 Jan '18

#14718: Add Boolean type families to 'base' package -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.5 Libraries | Keywords: base, type | Operating System: Unknown/Multiple families, Bool | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sometimes you want type families to perform type level computation with booleans. Specifically: {{{#!hs type family If (p :: Bool) (ifTrue :: k) (ifFalse :: k) :: k where ... type family (a :: Bool) && (b :: Bool) :: Bool where ... type family (a :: Bool) || (b :: Bool) :: Bool where ... type family Not (a :: Bool) :: Bool where }}} Similar to existing module [https://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Bool.html Data.Bool] in `base` package for boolean expressions. There's not a single package with such type families for type-level boolean computations. Even if it exists it probably would very small. And as a library author you probably don't wan extra dependencies for your package because cost of adding new dependency for your project is much bigger than cost of adding module to existing dependencies (if it's possible of course). It seems to me that such operations are kinda basic. And they just promote behavior of already existed expression-level functions to type level. And we already have type families for `Integer`, `Natural` and `String` (aka `Symbol`) and several type families returning `Bool` (`==`, `<=?`) in `base`. So I propose to add couple useful utilities to operate with `Bool` explicitly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14718> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14688: Note [Lone variables] leads to missing a case-of-case opportunity
by GHC 26 Jan '18

26 Jan '18

#14688: Note [Lone variables] leads to missing a case-of-case opportunity -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- After the simplifier, my program ends up in the following state. {{{ foo = \f s -> let x = case s of { T1 a b -> a :> b :> Nil } in fmap (\v -> case x of { _v1 :> vs -> T1 v (case vs of {v2 :> _ -> v2}) }) (f (case x of {v1 :> _ -> v1})) }}} Now if I understand `Note [Lone variables]` correctly, `x` is NOT inlined into the call sites, no matter what I do as `x` is work-free. However, this is bad as if we were to inline `x` we get a case-of-case opportunity. {{{ => Inline foo = \f s -> let x = case s of { T1 a b -> a :> b :> Nil } in fmap (\v -> case (case s of { T1 a b -> a :> b :> Nil }) of { _v1 :> vs -> T1 v (case vs of {v2 :> _ -> v2}) }) (f (case x of {v1 :> _ -> v1})) => case of case foo = \f s -> let x = case s of { T1 a b -> a :> b :> Nil } in fmap (\v -> case s of { T1 a b -> case (a :> b :> Nil) of { _v1 :> vs -> T1 v (case vs of {v2 :> _ -> v2}) }) (f (case x of {v1 :> _ -> v1})) => case of known constructor foo = \f s -> let x = case s of { T1 a b -> a :> b :> Nil } in fmap (\v -> case s of { T1 a b -> T1 v b}) (f (case x of {v1 :> _ -> v1})) => Same for the other branch foo = \f s -> fmap (\v -> case s of { T1 a b -> T1 v b}) (case s of T1 a b -> a) }}} Which no longer mentions the intermediate representation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14688> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7414: plugins always trigger recompilation
by GHC 25 Jan '18

25 Jan '18

#7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: plugin, | RecompilationCheck 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: | -------------------------------------+------------------------------------- Changes (by mpickering): * priority: normal => high * milestone: => 8.6.1 Comment: Is there anything blocking this ticket or does someone just need to implement it? It makes using plugins quite a bit more hassle than necessary. See also #12567 I really think this should be a priority for the next release (8.6) Ben said in an email thread last year that these should be the steps. But, if the implementation is slightly broken, implementing anything will be better than the current situation I posit! We can get back to the current situation by using `-fforce-recomp` after all. {{{ I think the real question is what sort of interface do plugin authors need? I suspect there are a few distinct tasks here, * compute and record module implementation hashes in interface files * to include plugin implementation hashes in the recompilation check * to provide an interface allowing a plugin to compute a hash of its arguments which can be included into the recompilation check. One way of realising this would be to add a field like the following to Plugin, pluginHash :: [CommandLineOption] -> Maybe Fingerprint -- Nothing would denote "always rebuild" Would this help in your case? This would allow us to fix the TH problem in #7277 and fix the plugins problem in #7414 and #12567 in a nearly optimal way (assuming the plugin author is able to precisely define a hash). None of this is terribly difficult and given Nick's recent work on his row types plugin, it seems like it's getting more urgent. Cheers, - Ben }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7414#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5793: make nofib awesome
by GHC 25 Jan '18

25 Jan '18

#5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): > Fixup the runtimes for benchmarks to be significant. This might be best done by changing the way we run benchmarks and collect results to make sure they are meaningful. Windows suffers especially from this as the cpuTime measurement has less accuracy there. See #14714 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5793#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14714: RTS Timings on windows are somewhat unreliable
by GHC 25 Jan '18

25 Jan '18

#14714: RTS Timings on windows are somewhat unreliable -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Times given by the RTS are very unreliable on small scales. Part of that is I assume simply the lack of precision. But CPU Time often is reported higher than wall clock time (using the single threaded RTS) as well. Examples: {{{ $ ./binary-trees 12 +RTS -t stretch tree of depth 13 check: -1 ... long lived tree of depth 12 check: -1 <<ghc: 43098232 bytes, 42 GCs, 345148/647488 avg/max bytes residency (2 samples), 3M in use, 0.000 INIT (0.000 elapsed), 0.016 MUT (0.009 elapsed), 0.000 GC (0.003 elapsed) :ghc>> $ ./binary-trees 12 +RTS -t stretch tree of depth 13 check: -1 8192 trees of depth 4 check: -8192 ... 32 trees of depth 12 check: -32 long lived tree of depth 12 check: -1 <<ghc: 43098232 bytes, 42 GCs, 345148/647488 avg/max bytes residency (2 samples), 3M in use, 0.000 INIT (0.000 elapsed), 0.000 MUT (0.010 elapsed), 0.016 GC (0.003 elapsed) :ghc>> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14504: Nofib is broken on Windows
by GHC 25 Jan '18

25 Jan '18

#14504: Nofib is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: NoFib | Version: 8.2.1 benchmark suite | 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: -------------------------------------+------------------------------------- It seems like nofib is currently broken on Windows. Specifically, it fails for me with {{{ ... /home/ben/ghc/inplace/bin/ghc-stage2 -M -dep-suffix "" -dep-makefile .depend -osuf o -O2 -Rghc-timing -H32m -hisuf hi -rtsopts -XBangPatterns -O2 Main.hs <<ghc: 21000792 bytes, 9 GCs, 781824/1421072 avg/max bytes residency (2 samples), 26M in use, 0.000 INIT (0.000 elapsed), 0.031 MUT (0.037 elapsed), 0.016 GC (0.022 elapsed) :ghc>> Finished making boot in fannkuch-redux: 0 ------------------------------------------------------------------------ == make boot --no-print-directory; in /home/ben/ghc/nofib/shootout/fasta ------------------------------------------------------------------------ $topdir/../mingw/bin/gcc.exe -std=gnu99 -O3 -fomit-frame-pointer fasta-c.c -o fasta-c /bin/sh: /../mingw/bin/gcc.exe: No such file or directory }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14504> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14646: GHC 8.4.1 regression: rank-n types no longer parenthesized when pretty-printed
by GHC 24 Jan '18

24 Jan '18

#14646: GHC 8.4.1 regression: rank-n types no longer parenthesized when pretty- printed -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Take this file: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where import Language.Haskell.TH $([d| f :: (forall a. a) -> Int f _ = undefined |]) }}} In GHC 8.2.2, `-ddump-splices` behaves as you'd expect: {{{ $ /opt/ghc/8.2.2/bin/ghci Bug.hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(8,3)-(9,24): Splicing declarations [d| f_a1zL :: (forall a_a1zM. a_a1zM) -> Int f_a1zL _ = undefined |] ======> f_a49Z :: (forall a_a4a0. a_a4a0) -> Int f_a49Z _ = undefined Ok, one module loaded. }}} But in GHC 8.4.1-alpha (and HEAD), the GHC pretty-printer incorrectly leaves off the parentheses around the type `(forall a. a)`: {{{ $ /opt/ghc/8.4.1/bin/ghci Bug.hs GHCi, version 8.4.0.20171222: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(8,3)-(9,24): Splicing declarations [d| f_a1EF :: (forall a_a1EG. a_a1EG) -> Int f_a1EF _ = undefined |] ======> f_a4ap :: forall a_a4aq. a_a4aq -> Int f_a4ap _ = undefined Ok, one module loaded. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14646> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14707: setNumCapabilities can cause threads to get stuck in gcWorkerThread
by GHC 24 Jan '18

24 Jan '18

#14707: setNumCapabilities can cause threads to get stuck in gcWorkerThread -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.5 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: -------------------------------------+------------------------------------- I have a patch with some instrumentation that proves that sometimes threads do not leave gcWorkerThread until the following gc. I suspect it's caused by `idle_caps` being mutated in `scheduleDoGC` after the call to `requestSync`. A thread enters `yieldCapability` sees that itself is not idle, so enters `gcWorkerThread`, but then `idle_caps` is mutated so that that thread *is* idle, and it's spin locks are not touched by the garbage collector. Potential fixes: * Don't look at `idle_caps` in the garbage collector when we're touching the spin-locks, just do it for all capabilities. I don't *think* this does any harm. * Don't mutate `idle_caps` after the call to `requestSync`; move that logic to before the call. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14707> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11138: Kill the terrible LLVM Mangler
by GHC 24 Jan '18

24 Jan '18

#11138: Kill the terrible LLVM Mangler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since its introduction the LLVM backend has had a mangler which transforms assembler produced by LLVM. In the past this mangler was responsible for shuffling around code to make tables-next-to-code work, but the need for this has past with the resolution of #4213. At this point the only reason it exists is to mangle AVX instructions to 1. rewriting all symbols of type `@function` to `@object` to prevent symbol references from going through the PLT, which would be bad due to tables-next-to-code. 2. On x86_64, rewrite AVX instructions that require alignment to their unaligned counterparts, since the stack is only 16-byte aligned but these instructions require 32-byte alignment. While it's unclear that we will ever be able to discharge (1), it would be nice to investigate whether we can at least do something about (2) (there may even be performance to be gained!). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11138> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12470: Move LLVM code generator to LLVM bitcode format
by GHC 24 Jan '18

24 Jan '18

#12470: Move LLVM code generator to LLVM bitcode format -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (LLVM) | 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: -------------------------------------+------------------------------------- Currently GHC produces LLVM's textual intermediate representation. While this is easy to produce, it's not the path recommended by LLVM's developers. Instead, they [[http://llvm.org/docs/DeveloperPolicy.html#ir- backwards-compatibility|recommend]] that compilers produce LLVM bitcode, which they maintain much stronger backwards compatibility guarantees on. It seems sensible to move the backend over to this format. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12470> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3