July 2017 - ghc-tickets

[GHC] #10892: ApplicativeDo should use *> and <*
by GHC 05 Mar '19

05 Mar '19

#10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- From @ekmett: Would it be possible to tweak the generation to use `(<*)` or `(*>)` where appropriate when the result isn't being used? For many Applicatives this can be a massive asymptotic win in terms of sharing and/or computational cost. When desugaring using (<*) you'd just omit any handling of the unused result instead. {{{ (\x y -> ...) <$> foo <* bar <*> baz }}} corresponds to {{{ do x <- foo bar y <- baz return ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10892> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #13633: testwsdeque failure on POWER8
by GHC 04 Mar '19

04 Mar '19

#13633: testwsdeque failure on POWER8 ---------------------------------------+---------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Keywords: SMP | Operating System: Linux Architecture: powerpc64 | Type of failure: Runtime crash Test Case: rts/testwsdeque | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+---------------------------------- On a POWER8 `testwsdeque` fails occasionally under load: {{{ Wrong exit code for testwsdeque(threaded1)(expected 0 , actual 134 ) Stderr ( testwsdeque ): internal error: FAIL: 277808608 3 13 (GHC version 8.3.20170430 for powerpc64le_unknown_linux) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13633> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14037: Fix fusion for GHC's utility functions
by GHC 04 Mar '19

04 Mar '19

#14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- In a patchset I'm working on, I encountered a smallish "bytes allocated" regression in `perf/compiler/T5631`. After some sleuthing, I discovered that the regression is caused by using a `zipWith3M` where previously there was a `zipWithM`. Interestingly, it was not the zipped function that caused the problem, but the `zipWith3M` itself. Further sleuthing found that `zipWithM` is inlined into a combination of `sequenceA` and `zipWith`, both of which have been taught to work nicely with fusion. I thought of doing the same to GHC's `zipWith3M`, but I discovered that `base`'s `zipWith3` has no rules or inlining pragmas, suggesting that it does not fuse. I was quite surprised to find this, thinking that all functions as basic as `zipWith3` in `base` would play nicely with fusion. (Perhaps it does fuse -- I didn't actually check.) I then checked out GHC's `MonadUtils`, which defines a bunch of functions, some of which must be hammered on, and only one of which has any kind of performance- enhancing pragma. (The one is `zipWithAndUnzipM`, whose `INLINABLE` pragma was added only after much pain suffered by your dear author.) So: this ticket is a request to sweep through `MonadUtils` and `Util` and perhaps `ListSetOps`, looking for performance enhancements via fusion, tighter definitions, and such. Also, get `zipWith3` (and the other `zipWith`s) to fuse in `base`. I figure this is all some fairly low-hanging fruit for performance improvements in GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14037> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8657: -fregs-graph still has a limit on spill slots
by GHC 04 Mar '19

04 Mar '19

#8657: -fregs-graph still has a limit on spill slots -----------------------------------+--------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (NCG) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- The limit on spill slots was removed for the linear register allocator in 7.8, but not for `-fregs-graph`. SHA-1 fails to compile with `-fregs-graph` in 7.8. Related: #7679 (`-fregs-graph` generates poor code with the new codegen). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8657> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #12919: Equality not used for substitution
by GHC 04 Mar '19

04 Mar '19

#12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- This code {{{ {-# LANGUAGE TypeInType, TypeFamilies, GADTs, ConstraintKinds #-} import Data.Kind data N = Z data V :: N -> Type where VZ :: V Z type family VC (n :: N) :: Type where VC Z = Type type family VF (xs :: V n) (f :: VC n) :: Type where VF VZ f = f data Dict c where Dict :: c => Dict c prop :: xs ~ VZ => Dict (VF xs f ~ f) prop = Dict }}} fails with this error: {{{ Op.hs:20:8: error: • Couldn't match type ‘f’ with ‘VF 'VZ f’ arising from a use of ‘Dict’ ‘f’ is a rigid type variable bound by the type signature for: prop :: forall (xs :: V 'Z) f. xs ~ 'VZ => Dict VF xs f ~ f at Op.hs:19:9 • In the expression: Dict In an equation for ‘prop’: prop = Dict • Relevant bindings include prop :: Dict VF xs f ~ f (bound at Op.hs:20:1) }}} However, if I substitute `xs` with `VZ` (by hand) in the type of `prop`, it compiles. Can be reproduced with GHC 8.0.1 but not HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12919> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let
by GHC 04 Mar '19

04 Mar '19

#11982: Typechecking fails for parallel monad comprehensions with polymorphic let -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE MonadComprehensions, ParallelListComp #-} module Foo where foo xs ys = [ (f y True, f x 'c') | let f _ z = z, x <- xs | y <- ys ] }}} This fails with {{{ Foo.hs:5:52: error: * Cannot instantiate unification variable `t0' with a type involving foralls: forall t2 t3. t3 -> t2 -> t2 GHC doesn't yet support impredicative polymorphism * In a stmt of a monad comprehension: let f _ z = z, x <- xs | y <- ys In the expression: [(f y True, f x 'c') | let f _ z = z, x <- xs | y <- ys] In an equation for `foo': foo xs ys = [(f y True, f x 'c') | let f _ z = z, x <- xs | y <- ys] }}} NB: `ApplicativeDo` has a related problem: the implementation is quite different and has the effect of monomorphising the let-bound variable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11982> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #9894: Presence of DWARF debug symbols doesn't result in working backtraces in GDB
by GHC 04 Mar '19

04 Mar '19

#9894: Presence of DWARF debug symbols doesn't result in working backtraces in GDB ----------------------------------+--------------------------------------- Reporter: tibbe | Owner: scpmw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------------- Now when GHC can output DWARF debug symbols we need to take the remaining steps needed to get downstream tool like GDB to do something useful with it. As of today GDB cannot produce a valid stack trace for this code: {{{#!hs module Main where import System.IO f name = print $ "Hello, " ++ name {-# NOINLINE f #-} g name = f name {-# NOINLINE g #-} main = do name <- getLine g name }}} when a breakpoint is set on the line that defines `f` before the program is run. The resulting backtrace looks like: {{{ (gdb) bt #0 Main_f_info () at /tmp/Test.hs:5 #1 0x0000000000481a00 in ?? () Backtrace stopped: frame did not save the PC }}} This bug tracks the remaining work that needs to be done before this will work. Peter, what is the remaining work here? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9894> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9910: ghc's dwarf (-g) output does not like Unicode (Char.intToDigit: not a digit 136)
by GHC 04 Mar '19

04 Mar '19

#9910: ghc's dwarf (-g) output does not like Unicode (Char.intToDigit: not a digit 136) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Easy to reproduce as: {{{ inplace/bin/ghc-stage2 -w -g -c testsuite/tests/parser/unicode/utf8_024.hs ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20141219 for x86_64-unknown-linux): Char.intToDigit: not a digit 136 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{ petermw> Yes, Unicode doesn't work with DWARF yet }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9910> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10236: DWARF unwind info is broken
by GHC 04 Mar '19

04 Mar '19

#10236: DWARF unwind info is broken -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.10.2 Priority: high | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple (Debugging) | Type of failure: Incorrect result Keywords: dwarf | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D792 | -------------------------------------+------------------------------------- As reported by `bitonic` and `petermw` on `#ghc` (April 2nd): {{{ 07:02 < bitonic> I'm trying to get a meaningful backtrace with DWARF, using <https://ghc.haskell.org/trac/ghc/wiki/DWARF> as a guide. however, all I get is `Backtrace stopped: previous frame identical to this frame (corrupt stack?)` 07:03 < bitonic> I've re-built GHC 7.10.1 using `GhcRtsHcOpts += -g` and `GhcLibHcOpts += -g`, even if I'm not sure it's even necessary 07:04 < bitonic> are there any additional steps I should take? or any way to make sure that the binary I'm generating is sane? }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10236> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10915: Statistical profiling support in the RTS
by GHC 04 Mar '19

04 Mar '19

#10915: Statistical profiling support in the RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D1215, | Phab:D1214 | -------------------------------------+------------------------------------- Now since GHC can produce useful debugging information (e.g. DWARF annotations and source notes) in compiled objects, it would great if we could leverage this for more efficient profiling. While ideally we would be able to rely on external tools like `perf` for this task, this would require that the STG stack be walkable like a standard C stack. A more feasible alternative is to incorporate a simple statistical profiler into the RTS. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10915> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12