October 2018 - ghc-tickets

[GHC] #15742: GHC configure step can fail when CC=clang
by GHC 11 Oct '18

11 Oct '18

#15742: GHC configure step can fail when CC=clang ----------------------------------------+--------------------------------- Reporter: judah | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- In our internal build of GHC from source, we are building it on Linux with Clang. Unfortunately, this results in an error on ghc-8.4.3: {{{ $ ./configure CC=clang CC_STAGE0=clang --prefix=... --with-ghc=... ... checking version of gcc... configure: error: Need at least gcc version 4.4 (4.7+ recommended) }}} Looking in the code, it seems that the logic is wrong: it calls `$CC -v` and parses the output unconditionally, whether or not the compiler is actually GCC: https://github.com/ghc/ghc/blob/ce7a1c4ae4c93f2d0d3d7a0b573ddd876fc855c2/ac… In our case, the test fails since the compiler is a build of Clang that doesn't produce a useful version number. I also realized that on macOS (where gcc *is* clang), this test succeeds accidentally, since the output of {{{gcc -v}}} is: {{{ Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with- gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 10.0.0 (clang-1000.10.44.2) Target: x86_64-apple-darwin17.7.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin judahjacobson-macbookpro:~ judahjacobson$ gcc -v Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with- gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 10.0.0 (clang-1000.10.44.2) Target: x86_64-apple-darwin17.7.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15741: Accept GHCRTS=-N1 when not compiled with -threaded
by GHC 11 Oct '18

11 Oct '18

#15741: Accept GHCRTS=-N1 when not compiled with -threaded -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.6.1 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: -------------------------------------+------------------------------------- current behaviour: {{{ > ghc Main.hs -o test > ./test +RTS -N1 test: the flag -N1 requires the program to be built with -threaded [blah blah] }}} requested: {{{ > ghc Main.hs -o test > ./test +RTS -N1 hello world }}} Motivation: In certain environments, threaded is bad idea due to resource constraints even when multiple capabilities are available, because resident memory can increase with parallel execution. Slapping GHCRTS=-N1 onto those environments would be nice, but breaks for things not compiled with -threaded. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15741> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code
by GHC 11 Oct '18

11 Oct '18

#15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Keywords: | 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: -------------------------------------+------------------------------------- At ICFP, I griped to Ben about some code I'm writing (which makes use of `singletons` to the nth degree) that takes absolutely forever to compile with optimizations. I suspected that type families (i.e., coercions) were the culprit, but Ben requested that I put the code on Trac anyways, so here it is. I've attached two modules (`Lib.hs` and `Lib2.hs`). You'll need GHC 8.6.1 or later to compile it. To compile it, run: {{{ $ time /opt/ghc/8.6.1/bin/ghc -O1 -fforce-recomp Lib.hs [1 of 2] Compiling Lib2 ( Lib2.hs, Lib2.o ) [2 of 2] Compiling Lib ( Lib.hs, Lib.o ) real 3m28.367s user 3m28.512s sys 0m0.212s }}} Note that if you compile without optimizations, it'll finish almost immediately: {{{ $ time /opt/ghc/8.6.1/bin/ghc -O0 -fforce-recomp Lib.hs [1 of 2] Compiling Lib2 ( Lib2.hs, Lib2.o ) [2 of 2] Compiling Lib ( Lib.hs, Lib.o ) real 0m0.528s user 0m0.480s sys 0m0.036s }}} Also, if you look at the source code for `Lib.hs`, you'll notice some code which says: {{{#!hs instance SApplicative f => SApplicative (M1 i c f) where sPure x = singFun3 @(.@#@$) (%.) @@ singFun1 @M1Sym0 SM1 @@ (singFun1 @PureSym0 sPure) @@ x -- If I change the implementation of sPure above to be this: -- -- sPure x = SM1 (sPure x) -- -- Then Lib.hs compiles quickly again (< 1 second) with -O1. SM1 f %<*> SM1 x = SM1 (f %<*> x) }}} If you apply this suggested change, then you can see the difference when you compile it with optimizations again: {{{ $ time /opt/ghc/8.6.1/bin/ghc -O1 -fforce-recomp Lib.hs [1 of 2] Compiling Lib2 ( Lib2.hs, Lib2.o ) [2 of 2] Compiling Lib ( Lib.hs, Lib.o ) real 0m0.986s user 0m0.940s sys 0m0.040s }}} Given that this particular change of code causes such a dramatic increase in compilation, I have to wonder if there's more going on here than just the usual type-family slowness. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15703> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #15739: ghc-heap: code field never seems to be populated in StgInfoTable
by GHC 11 Oct '18

11 Oct '18

#15739: ghc-heap: code field never seems to be populated in StgInfoTable -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- It seems that `peekItbl` doesn't populate the `code` field of `StgInfoTable`. https://github.com/ghc/ghc/blob/6bb9bc7d3c935dcb77e0700cce28de2c9df646df/li… /ghc-heap/GHC/Exts/Heap/InfoTable.hsc#L52 If you look at `InfoTables.h`, when `TABLES_NEXT_TO_CODE`, it should be populated. https://github.com/ghc/ghc/blob/1c2c2d3dfd4c36884b22163872feb87122b4528d/in… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15737: Implement sconcat Semigroup Instances for Tuples
by GHC 11 Oct '18

11 Oct '18

#15737: Implement sconcat Semigroup Instances for Tuples -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- For some semigroups, the user-defined `sconcat` performs asymptotically better than the default. The semigroup instances for tuples should create a list of each component individually, use `sconcat` for the underlying type, and then zip the tuples back together. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15737> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15603: ref6 example from StaticPointers documentation doesn't type check
by GHC 11 Oct '18

11 Oct '18

#15603: ref6 example from StaticPointers documentation doesn't type check -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- The [https://downloads.haskell.org/~ghc/8.4.3/docs/html/users_guide/glasgow_exts… #extension-StaticPointers documentation] for `StaticPointers` contains the following example. {{{ ref6 y = let x = 1 in static x }}} but this doesn't get accepted by the type checker. {{{ sp.hs:27:23: error: • ‘x’ is used in a static form but it is not closed because it has a non-closed type because it contains the type variables: ‘p_a7KP’ • In the expression: static x In the expression: let x = 1 in static x In an equation for ‘ref6’: ref6 y = let x = 1 in static x | 27 | ref6 y = let x = 1 in static x | ^^^^^^^ }}} I tested on 8.6.1, 8.4.3, 8.2.2, 8.02, 7.10.3 and all fail. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15603> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13923: Add a suppression flag to stop Typeable bindings being emitted with -ddump-simpl
by GHC 11 Oct '18

11 Oct '18

#13923: Add a suppression flag to stop Typeable bindings being emitted with -ddump- simpl -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: low | 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: -------------------------------------+------------------------------------- When reading core output, it is very distracting to always have to wade through a large number of bindings generated by `Typeable`. In most cases I don't care about any of these so it would be easier if there was some way to stop them being printed or being generated in the first place. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13923> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15332: lintIdUnfolding could be simpler
by GHC 11 Oct '18

11 Oct '18

#15332: lintIdUnfolding could be simpler -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4919 | Wiki Page: -------------------------------------+------------------------------------- I think that `lintIdUnfolding` could use `maybeUnfoldingTemplate` rather than the complicated linting of `DFunUnfolding`. Seeing as `maybeUnfoldingTemplate` is the thing which is used when inlining, it makes sense to use that rather than some ad-hoc reconstruction. See https://phabricator.haskell.org/D4919 for the patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15332> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15734: ghc-heap package is not on hackage
by GHC 10 Oct '18

10 Oct '18

#15734: ghc-heap package is not on hackage -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- The documentation for ghc-heap is quite hidden away here: https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc- heap-8.6.1/GHC-Exts-Heap.html It would be useful if it was on hackage so that it had better discoverability and was easier to browse the documentation like the normal `ghc` package. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15734> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13128: Refactor AvailInfo to be more sensible
by GHC 10 Oct '18

10 Oct '18

#13128: Refactor AvailInfo to be more sensible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: new Priority: low | 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: -------------------------------------+------------------------------------- `AvailInfo` has been the bane of my life for the last 12 months and I want to tame it. There are two main problems with it. 1. There is this horrible invariant where if the parent is also exported then it is the first element of the list of children. 2. The set of children and field labels are represented as lists which means many expensive calls to functions from `ListSetOps`. 1 Is easy enough to solve by adding a flag which says whether the parent is exported or not. My naive attempt to solve the second problem was to replace the list by a `NameSet`. At the interface file boundary, the `NameSet` is converted into a list using `nameSetElemsStable` to maintain determinism and only pay the cost of using this expensive function once. This ran into problems in `RnModIface` where there are several functions which map over the list of children. NameSets don't support mapping and so this is difficult to implement in a satisfactory way. The next plan of attack is to distinguish between `IfaceAvailInfo` and `AvailInfo`. The former will use the old representation (lists) in order to maintain determinism but the latter will use sets. Distinguishing the two modes is useful conceptually and practically. The data type is used in quite a few different ways in lots of places which makes writing a nice interface hard. This ticket is to record my trail in case I don't make it to the end. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13128> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5