September 2018 - ghc-tickets

[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 26 Nov '18

26 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] #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

[GHC] #13773: Types are not normalized in instance declarations
by GHC 25 Nov '18

25 Nov '18

#13773: Types are not normalized in instance declarations -------------------------------------+------------------------------------- Reporter: augustss | 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the example below. It does not compile, but replacing 5*2 by 10 makes it compile. This is quite annoying since it forces me to do the normalization that the computer is really much better at doing. {{{#!hs module NatInstance where import GHC.TypeLits type N = 5 * 2 data D (n :: Nat) = D instance Show (D N) where show _ = "" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13773> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15085: :type-at/:all-types and :r don't mix
by GHC 25 Nov '18

25 Nov '18

#15085: :type-at/:all-types and :r don't mix -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Steps to reproduce: 1. Put `x = ()` in test.hs. 2. Start ghci. 3. Turn on collection with :set +c. 4. Load the file with :l test.hs. 5. Observe the following output from :all-types {{{ test.hs:(1,1)-(1,2): () test.hs:(1,5)-(1,7): () }}} 6. While ghci is still open, modify the file to say `x = True`. 7. In the same ghci session as before, reload with :r, or load the file again with :l test.hs, chef's choice. 8. Run :all-types again. After step 8, ghci prints the exact same thing as before, indicating that both sides of the equation have type `()`. It should instead update the source spans and types to match the file, reporting `Bool` instead of `()` and `(1,5)-(1,9)` for the second span. Manually exiting and restarting ghci appears to be the only way to freshen the collected type information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15085> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15495: Handling Source Locations via TTG
by GHC 24 Nov '18

24 Nov '18

#15495: Handling Source Locations via TTG -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 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: -------------------------------------+------------------------------------- == Problem == The current implementation of [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGr… TTG HsSyn AST] in GHC stores source locations for terms of a datatype `Exp` in a separate wrapper datatype `LExp` which is mutually recursive with `Exp` such that every recursive reference to `Exp` is done **indirectly**, via a reference to the wrapper datatype `LExp` (see the example code below). We refer to this style of storing source locations as the ping-pong style. Besides the indirection and the resulting complications of the ping-pong style, there are two key problems with it: a. It bakes-in the source locations in the base TTG AST, forcing all instances to store source locations, even if they don't need them.For example, TH AST does not carry source locations, or even within GHC, there are generated terms without source locations. b. It results in a form of conceptual redundancy: source locations are tree decorations and they belong in the extension points. (see https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGr… TTG Guidance]) == Solution == We can move the source location decorations to a wrapper constructor and remove the ping-pong style. This can be done smoothly, mechanically, and gradually by using a getter/setter methods for source locations. More details can be found at [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSou… the related wiki page]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15495> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1)
by GHC 23 Nov '18

23 Nov '18

#15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHCs detection of unused imports used to be very precise. But apparently this changed with GHC 8.0.1. I already noticed for a while that there is something fishy going on and finally came up with a minimal example. == Steps to reproduce: {{{#!hs -- Bar.hs module Bar (bar, module Control.Monad) where import Control.Monad bar :: Integer bar = 23 }}} {{{#!hs -- Foo.hs module Foo where import Bar import Control.Monad (forM_) foo :: Monad m => [a] -> (a -> m ()) -> m () foo = forM_ baz :: Integer baz = bar }}} {{{ $ ghci -Wall -Werror Foo.hs }}} **Expected result:** The program is reject. **Actual result:** The program was reject by GHC < 8.0.1, however later versions of GHC accept the program. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15393> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15319: Configurable/overridable settings file
by GHC 23 Nov '18

23 Nov '18

#15319: Configurable/overridable settings file -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- GHC ships with a `settings` file. This file specifies what was known about the C compiler at GHC `./configure` time (whether to pass `-no-pie` etc, the path to the C compiler etc). Fortunately, I can override at least some of the entries of the `settings` file, e.g. to use a different GCC than the one GHC got to know about during the `./configure` phase. This is important because is multi-lingual projects, sometimes the build tool for the C++ part of the code wants a special compiler, which GHC should also be using when compiling C. The problem is that I can't override *everything*. If I supply via `-pgmc` a compiler that doesn't understand `-no-pie`, then I can't tell GHC to not pass `-no-pie`. Because I can't supply my own `settings` file, or (equivalently) there exists no CLI flag that allows me to override that particular entry in the `settings` file. What I'd like is something like: {{{ $ ghc -settings /path/to/settings/file }}} that subsumes `-pgmc` and other such flags. I'd be able to tell GHC in one go which compiler I want to use, and what flags GHC should or should not pass to that compiler depending on the features of the compiler. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15319> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH
by GHC 22 Nov '18

22 Nov '18

#15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------------+---------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- I believe this is the same issue that is causing manually built `haddock` and `doctest` to crash on MacOS when fed TH (originally reported https://github.com/haskell/haddock/issues/767 and https://github.com/sol/doctest/issues/199) I've attached a minimal program that uses the GHC API and exhibits the same problem. {{{ $ ghc-8.4.2 -package ghc -package containers -package ghc-paths Prog.hs [1 of 1] Compiling Main ( Prog.hs, Prog.o ) Linking Prog ... $ ./Prog Main-no-TH.hs -package template-haskell $ ./Prog Main-TH.hs -package template-haskell Prog: lookupSymbol failed in relocateSection (RELOC_GOT) /usr/local/lib/ghc-8.4.2/integer-gmp-1.0.2.0/HSinteger-gmp-1.0.2.0.o: unknown symbol `___gmp_rands' Prog: Prog: unable to load package `integer-gmp-1.0.2.0' }}} In case it isn't clear, I do not expect `Main-TH.hs` to crash `Prog`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15105> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18