March 2017 - ghc-tickets

[GHC] #12181: Multi-threaded code on ARM64 GHC runtime doesn't use all available cores
by GHC 27 Mar '17

27 Mar '17

#12181: Multi-threaded code on ARM64 GHC runtime doesn't use all available cores -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Runtime | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is the machine: [http://www.cnx-software.com/2016/04/30/setup-guide-mini-review-of-bq- aquaris-m10-ubuntu-edition-tablet-from-a-developers-perspective/] Haskell ray-tracer that uses Control.Parallel.Strategies and parBuffer that is working well on x64 machine and using all the cores available use only 2 cores from 4 in total on that ARM machine. This machine usually work on two cores only and when it sees that they are used more - it enables two more to get total of four cores. If I give "+RTS -N4" it works just fine. So I think the problem is that the runtime doesn't check for all available cores, but only for enabled. In the first link you could see that "lscpu" returns 4 cores in total. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12181> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #1851: "make install-strip" should work
by GHC 27 Mar '17

27 Mar '17

#1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: It's unlikely this will be fixed for 8.2; de-milestoning until someone picks it up. Moreover, we will hopefully have Hadrian soon. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1851#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 27 Mar '17

27 Mar '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK great, thank you! Neither example on your status page use I/O, and I think it may be there that the main gains are to be found. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:72> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9418: Warnings about "INLINE binder is (non-rule) loop breaker"
by GHC 27 Mar '17

27 Mar '17

#9418: Warnings about "INLINE binder is (non-rule) loop breaker" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Gabor rightly complains: I see literally ''thousands'' of these warnings (in yesterday's and) today's bootstraps: {{{ HC [stage 1] libraries/base/dist-install/build/GHC/Base.o *** Core Lint warnings : in result of Desugar (after optimization) *** {-# LINE 261 "libraries/base/GHC/Base.lhs #-}: Warning: [RHS of $c>>_arr :: forall r_agf a_adQ b_adR. (r_agf -> a_adQ) -> (r_agf -> b_adR) -> r_agf -> b_adR] INLINE binder is (non-rule) loop breaker: $c>>_arr {-# LINE 632 "libraries/base/GHC/Base.lhs #-}: Warning: [RHS of $c>>_apH :: forall a_adQ b_adR. GHC.Types.IO a_adQ -> GHC.Types.IO b_adR -> GHC.Types.IO b_adR] INLINE binder is (non-rule) loop breaker: $c>>_apH }}} }}} This is clearly unsatisfactory, because it is unsettling, and perhaps conceals more important warnings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9418> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12137: Warning about “INLINE binder is (non-rule) loop breaker” with `-dcore-lint`
by GHC 27 Mar '17

27 Mar '17

#12137: Warning about “INLINE binder is (non-rule) loop breaker” with `-dcore-lint` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With this code using `lens` {{{#!hs {-# Language TemplateHaskell #-} import Control.Lens data Config = Config { _companyName :: String } data AppState = AppState { _asConfig :: Config } makeClassy ''Config instance HasConfig AppState where config = undefined }}} gives {{{ $ ghci -ignore-dot-ghci -dcore-lint /tmp/tvQq.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tvQq.hs, interpreted ) *** Core Lint warnings : in result of Simplifier *** /tmp/tvQq.hs:10:10: warning: [RHS of $ccompanyName_a7EP :: Lens' AppState String] INLINE binder is (non-rule) loop breaker: $ccompanyName_a7EP *** Core Lint warnings : in result of Simplifier *** /tmp/tvQq.hs:10:10: warning: [RHS of $ccompanyName_a7EP :: Lens' AppState String] INLINE binder is (non-rule) loop breaker: $ccompanyName_a7EP Ok, modules loaded: Main. *Main> }}} ---- `makeClass` actually dumps {{{ <interactive>:64:54-72: Splicing declarations makeClassy ''Config ======> class HasConfig c_axo7 where config :: Lens' c_axo7 Config companyName :: Lens' c_axo7 String {-# INLINE companyName #-} companyName = (.) config companyName instance HasConfig Config where {-# INLINE companyName #-} config = id companyName = iso (\ (Config x_axo8) -> x_axo8) Config }}} Using that to create a small example ---- {{{#!hs data Config = Config { name :: String } class HasConfig a where config :: a -> Config companyName :: a -> String {-# INLINE companyName #-} companyName a = name (config a) instance HasConfig Config where {-# INLINE companyName #-} config = id companyName = name . config }}} which works perfectly fine without `-dcore-lint` but fails with {{{ $ ghci -ignore-dot-ghci -dcore-lint /tmp/tvQq.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tvQq.hs, interpreted ) *** Core Lint warnings : in result of Simplifier *** /tmp/tvQq.hs:11:3: warning: [RHS of $ccompanyName_a18Q :: Config -> String] INLINE binder is (non-rule) loop breaker: $ccompanyName_a18Q *** Core Lint warnings : in result of Simplifier *** /tmp/tvQq.hs:11:3: warning: [RHS of $ccompanyName_a18Q :: Config -> String] INLINE binder is (non-rule) loop breaker: $ccompanyName_a18Q Ok, modules loaded: Main. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12137> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 27 Mar '17

27 Mar '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): I made a wiki page with a few specific examples: [wiki:NestedCPR/Akio2017]. I think I'm now done with updating `extendSigsWithLam`. I'm going to run nofib again and look for more improvements to make. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:71> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13313: cabal08 broken
by GHC 27 Mar '17

27 Mar '17

#13313: cabal08 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- Upon updating the `Cabal` submodule from 19c278feb732f5797256ff28eb671440f5511c6c to e4c36b9dd51820f2380ce7a66f980c4e7b2e96fc the `cabal08` testcase broke. I've marked it as `expect_broken` for now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13313> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #3351: Generated ghc man page missing xrefs
by GHC 27 Mar '17

27 Mar '17

#3351: Generated ghc man page missing xrefs -------------------------------------+------------------------------------- Reporter: kaol | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Documentation | Version: 6.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => new * resolution: fixed => Comment: This was just reported again (#13488). It might be low priority, but it certainly is not good enough. Ideally, it would say > details in section “Name of the section” in the user manual, possibly with a link to some canonical online location. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3351#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13488: man page says "see foo" without having chapter "foo"
by GHC 27 Mar '17

27 Mar '17

#13488: man page says "see foo" without having chapter "foo" -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- the first instance is the reference to the manual itself: "Extensive documentation is available in various other formats including PDF and HTML; see below." where "below" is the rest of the document, which does not seem to contain any further mentioning/linking to the proper documentation. I think all other instances of "see ..." are similarly empty promises. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13488> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved
by GHC 26 Mar '17

26 Mar '17

#8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): I have not contributed to GHC before, and I would like to work on resolving this issue. Both haddock and flycheck should be able to use -fno-code to do a lot less work. Currently, haddock essentially turns off no-code when any modules use template haskell and flycheck uses no-link to work around both this issue and #10600. I think this can be resolved by having ghc itself enable codegen on home modules depended on by modules that use template haskell. I have a patch here [https://github.com/duog/ghc/tree/wip-nocode-th] which I just rebased onto your master. Note that the haddock submodule points to my github fork. downsweep is changed to do an additional pass over the modules, targetting any ModSummaries transitively depended on by a module that has LangExt.TemplateHaskell enabled. Those targeted modules have hscTarget changed from HscNothing to the default target of the platform. There are two shell scripts in the root of my fork which boot and run an ad-hoc benchmark of cabal haddock on the wreq library. This library uses template haskell to generate lenses, and imports home modules from modules that use template haskell. However, most modules are not imported from modules that use template haskell. With this patch, cabal haddock runs in about half the time. At least two points that need to be addressed: * Should this behaviour require an additional flag? It doesn't seem good for -fno-code to sometimes generate code. * Is the default target of the platform the correct choice? I would require some guidance to get this into a mergable state, if you are interested in taking this fix please let me know the next step. I am happy to use your phabricator if that is appropriate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8025#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0