- ghc-tickets - Haskell.org

[GHC] #14275: Large Haskell value unexpectedly gets an unfolding
by GHC 26 Sep '17

26 Sep '17

#14275: Large Haskell value unexpectedly gets an unfolding -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- While working on #14272 I was surprised to find that modifying `PrelRules` resulted in a great deal of recompilation. Afterall, it has only three exports: * `primOpRules`: A function headed by a rather large case analysis totaling a few hundred lines of code * `builtinRules`: A large `[CoreRule]` (consisting of a literal list with six entries concatenated with the much-larger `builtInIntegerRules`) * `caseRules`: A function of moderate size Intuitively, none of these things seemed particularly beneficial to inline. This is why I was slightly surprised to find that `builtinRules` (and all of its floated entries) had an unfolding, {{{ builtinRules :: [CoreRule] {- Strictness: m2, Unfolding: (: @ CoreRule builtinRules255 builtinRules1) -} }}} Of course, determining whether unfoldings are helpful is in general quite difficult. However, I can't help but wonder whether our heuristic isn't quite right. Afterall, the Haskell for `builtinRules` is quite large and consequently most users would be surprised to see GHC try to inline it. The only reason it looks so small is that GHC broke up the structure via float-out. I don't have any concrete ideas for addressing this at the moment but felt like I should write down the concern so it isn't lost. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14275> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14144: Standardize binary distribution doc files
by GHC 26 Sep '17

26 Sep '17

#14144: Standardize binary distribution doc files -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | Version: 8.2.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: -------------------------------------+------------------------------------- I'm making a pass at the documentation in general, and next up on my list is simplifying the building process a bit. I hope to create something like `docs/dist-install` that would collect and hold all of the generated documentation. This would help in writing the docs, as you could verify links, say, from the user's guide to the library documentation. This would also allow installation and distribution to mainly be a `cp`. While looking into this, I ran into some discrepancies between releases. The contents of !https://downloads.haskell.org/~ghc/VERSION/docs for [https://downloads.haskell.org/~ghc/7.10-latest/docs 7.10], [https://downloads.haskell.org/~ghc/8.0-latest/docs 8.0], and [https://downloads.haskell.org/~ghc/latest/docs 8.2] are all different. 8.0 dropped `*.ps` files and `haddock.pdf`. 8.2 now additionally holds a `windows` folder that has a wide array of binaries and documentation. Going back further, the `Cabal` user's guide used to be included. I searched around for a reason that it was dropped and only found a git commit citing the change from `docbook`. But now most sources use `Sphinx`, so we could generate and include them if we so wished. The `Cabal` guide can be found at: * https://www.haskell.org/cabal/users-guide/ (Version 1.24.2) * https://cabal.readthedocs.io/en/latest/ (Versions 2.0 and HEAD) The `Haddock` guide can be found at: * https://www.haskell.org/haddock/doc/html (Version 2.15.0) * https://haskell-haddock.readthedocs.io/en/latest/ (Versions 2.18.0 and HEAD) * https://downloads.haskell.org/~ghc/latest/docs/haddock.html.tar.xz (GHC release version) Unfortunately, the www.haskell.org links are the most prominent when Googled. To bring this back to a point, I would like to clean up the `docs` folder of the distribution. The `windows` folder inside seems like it might be a mistake. Additionally, `Cabal` and `Haddock` have ended up in strange positions, and I think they probably could both use the same solution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14144> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14265: kinded holes
by GHC 26 Sep '17

26 Sep '17

#14265: kinded holes -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- For value-level holes, ghc kindly mentions the expected type. It does not do the same for holes in type signatures: mentioning the expected kind. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14265> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14153: Change worker thread name to something mentioning original process name
by GHC 26 Sep '17

26 Sep '17

#14153: Change worker thread name to something mentioning original process name ----------------------------------------+--------------------------------- Reporter: enolan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Worker OS thread are renamed to `ghc_worker` when spawned. This is annoying when reading debugging messages that print the process name. For example, at work I'm debugging a segfault in a Haskell program and the kernel message just says `ghc_worker[21992]: segfault at 0 ip...` which doesn't tell me which of our Haskell programs is having the problem. I'd like to change this so it mentions the original name. On Linux, we can get that from the `program_invocation_name` global. `pthread_setname_np` has a maximum length of 15 characters, so we'll have to truncate it. I propose the first 13 characters of the original name followed by ":w". I'd just as soon not change the name in the first place but apparently this change was made to make it easier to distinguish worker threads from the main thread when debugging processes in gdb (commit 674c631ea111233daa929ef63500d75ba0db8858). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14153> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14276: T13168 is broken on Windows
by GHC 26 Sep '17

26 Sep '17

#14276: T13168 is broken on Windows ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Due to the lack of shared library support. {{{ Actual stderr output differs from expected: diff -uw "./typecheck/T13168/T13168.run/T13168.stderr.normalised" "./typecheck/T13168/T13168.run/T13168.run.stderr.normalised" --- ./typecheck/T13168/T13168.run/T13168.stderr.normalised 2017-09-26 00:20:55.835321400 -0400 +++ ./typecheck/T13168/T13168.run/T13168.run.stderr.normalised 2017-09-26 00:20:55.836298600 -0400 @@ -1,4 +0,0 @@ -Warning: -rtsopts and -with-rtsopts have no effect with -shared. - Call hs_init_ghc() from your main() function to set these options. -Warning: -rtsopts and -with-rtsopts have no effect with -shared. - Call hs_init_ghc() from your main() function to set these options. *** unexpected failure for T13168(normal) }}} Really this output is spurious anyways and in principle shouldn't affect the test passage. That being said, I don't see an easy way to filter it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #420: O'Haskell
by GHC 26 Sep '17

26 Sep '17

#420: O'Haskell -------------------------------------+--------------------------------- Reporter: mlbm | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: None | Version: None Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A -------------------------------------+--------------------------------- Comment (by Tamar Christina <tamar@…>): In [changeset:"abca29f3f3e19c4af452c1714be1bf33f4ac9180/ghc" abca29f3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="abca29f3f3e19c4af452c1714be1bf33f4ac9180" Adds mingw64 to the valid GHC OSs. Summary: This fixes hadrian#420 (https://github.com/snowleopard/hadrian/issues/420) specifically the "Unknown OS mingw64". Reviewers: austin, hvr, bgamari, Phyx Reviewed By: Phyx Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D4016 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/420#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14274: Host normalization causes problem with configure.
by GHC 26 Sep '17

26 Sep '17

#14274: Host normalization causes problem with configure. ----------------------------------------+---------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------- The host normalization we do causes problems with configure, because we change the triple autoconf seems to think we're always cross compiling on Windows. So `AC_CHECK_TARGET_TOOL` always fails and ends up looking for `-<toolname>`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14274> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable
by GHC 25 Sep '17

25 Sep '17

#14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- Consider this program, {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} module Test where import GHC.Exts import Data.Kind data TypeRep (a :: k) where Con :: TypeRep (a :: k) TrFun :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). TypeRep a -> TypeRep b -> TypeRep (a -> b) pattern Fun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern Fun arg res <- TrFun arg res where Fun arg res = undefined data Dynamic where Dynamic :: forall a. TypeRep a -> a -> Dynamic -- Removing this allows compilation to proceed {-# COMPLETE Con #-} dynApply :: Dynamic -> Dynamic -> Maybe Dynamic -- Changing Fun to TrFun allows compilation to proceed dynApply (Dynamic (Fun ta tr) f) (Dynamic ta' x) = undefined dynApply _ _ = Nothing }}} As written the program fails with, {{{ test.hs:34:1: warning: [-Woverlapping-patterns] Pattern match has inaccessible right hand side In an equation for ‘dynApply’: dynApply (Dynamic (Fun ta tr) f) (Dynamic ta' x) = ... | 34 | dynApply (Dynamic (Fun ta tr) f) (Dynamic ta' x) = undefined | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This can be worked around by doing one of the following, 1. Removing the `COMPLETE` pragma 2. Changing the use of the `Fun` pattern synonym into a use of the `TrFun` constructor. Something is quite wrong here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14253> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14188: On windows, trace prints out lines without proper line endings
by GHC 25 Sep '17

25 Sep '17

#14188: On windows, trace prints out lines without proper line endings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Try this on Windows {{{ module Foo where f x = x }}} and now {{{ ghc -c -dverbose-core2core Foo.hs 2> foo }}} Now edit `foo`. You'll see that * Some lines, produced by monadic IO, I think, have CRLF endings (`^M^J`). * But others, produced by `pprTrace` (actually `Simplify.hs` line 220, only have a LF ending (`^J`). The inconsistent line endings confuses emacs, which displays `^M` at the end of all the CRLF lines (ie most of them). This is Jolly Annoying. John Wiegley has made me a special SPJ-only emacs mimor mode that suppresses the annoying `^M` stuff, but that seems like extreme measures. Question: why doesn't `pprTrace` properly terminate its lines? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14188> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14264: unregisterised GHC fails buid as: ghc-stage1: panic! (the 'impossible' happened): pprCLbl AsmTempLabel
by GHC 24 Sep '17

24 Sep '17

#14264: unregisterised GHC fails buid as: ghc-stage1: panic! (the 'impossible' happened): pprCLbl AsmTempLabel -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- How to repdoruce on amd64: {{{ $ ./configure --enable-unregisterised $ make }}} Build failure: {{{ rts_dist_HC rts/dist/build/PrimOps.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170920 for x86_64-unknown-linux): ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170920 for x86_64-unknown-linux): ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170920 for x86_64-unknown-linux): pprCLbl AsmTempLabel }}} Normally UNREG backend has no asm labels. changeset:8b007abbeb3045900a11529d907a835080129176 looks vaguely relevant as it adds AsmTempLabel in one place. But I did not look in detail yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14264> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5