July 2018 - ghc-tickets

[GHC] #15418: Performance drop 60 times on non-profiling binary
by GHC 27 Sep '18

27 Sep '18

#15418: Performance drop 60 times on non-profiling binary ----------------------------------------+--------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- I have a rather large application that I have spent quite some time on tuning it as performance is just too bad. I have come to a point where the profiler reports about 14 seconds on a particular example, which is about 5x slower than I would like to see. However, building the same binary without profiling ability results in that the example takes 14 _minutes_. If I just touch a file and build with profiling information, but not giving it any profiling related RTS options, it takes about 30 seconds (not 14 seconds, but that is probably due to profiling overhead being there). How can performance drop 60x when I basically just relink it? From what I can see using "top" and memory profiling, memory consumption is quite stable over time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15418> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #8809: Prettier error messages?
by GHC 27 Sep '18

27 Sep '18

#8809: Prettier error messages? ------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- `clang` has very nice-looking error messages. {{{ #!html <pre>pretty.c:6:7: warning: incompatible pointer to integer conversion passing 'char [14]' to parameter of type 'int' [-Wint-conversion] foo("Hello, world!"); ^~~~~~~~~~~~~~~ pretty.c:1:14: note: passing argument to parameter 'i' here void foo(int i) { ^ 1 warning generated.</pre> }}} `ghc`'s error messages are not so good. {{{ #!html <pre>ugly.hs:7:18: Couldn't match expected type ‘()’ with actual type ‘[Char]’ In the first argument of ‘f’, namely ‘"Hello, world!"’ In the second argument of ‘($)’, namely ‘f "Hello, world!"’ In the expression: print $ f "Hello, world!"</pre> }}} In my opinion, there are three independent improvements that could be made to GHC error messages and warnings: color, context and whitespace. Currently they're blobs of text. Consider all three applied to error messages: {{{ #!html <pre>ugly.hs:7:18: error: Argument to 'f' is type '[Char]' but expected 'Int' main = print $ f "Hello, world!" ^~~~~~~~~~~~~~~ ugly.hs:3:1: note: type of 'f' is given here: f :: () -> IO () ^~</pre> }}} or {{{ #!html <pre>ugly.hs: note: type of 'f' is inferred: f :: forall m. Monad m => () -> m () ^~</pre> }}} In my opinion, context and whitespace are more important that color. Even without color, compare this error message to the one shown above: {{{ ugly.hs:7:18: error: Argument to 'f' is type '[Char]' but expected 'Int' main = print $ f "Hello, world!" ^~~~~~~~~~~~~~~ ugly.hs:3:1: note: type of 'f' is given here: f :: () -> IO () ^~ }}} In my opinion this is much easier to visually process than GHC's current messages. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8809> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 79

[GHC] #13147: Formatting is broken in Exceptions section of GHC.Prim haddock
by GHC 26 Sep '18

26 Sep '18

#13147: Formatting is broken in Exceptions section of GHC.Prim haddock -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 8.0.1 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: -------------------------------------+------------------------------------- Something seems to have gone wrong with how this documentation is rendered to HTML. https://hackage.haskell.org/package/ghc-prim-0.5.0.0/docs/GHC- Prim.html#g:14 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10990: Checking whether a default declaration is an instance of a defaultable typeclass is broken
by GHC 26 Sep '18

26 Sep '18

#10990: Checking whether a default declaration is an instance of a defaultable typeclass is broken -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (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: -------------------------------------+------------------------------------- In TcDefaults.hs, `tcDefaults` is supposed to check whether the supplied default type is an instance o `Num` or `IsString` (note the lack of extended defaults here, so this has been broken for quite some time). Following the code we can see that `simplifyDefault` in TcSimplify.hs calls `reportAllUnsolved` and it does report the error -- with typechecker tracing on we see {{{ Adding error: <interactive>:19:1: error: No instance for (Num []) arising from a 'default' declaration When checking the types in a default declaration }}} But typechecking never actually fails, so it returns `Just ()` regardless and the error gets swallowed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10990> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12848: Reduce long-term memory usage of GHCi
by GHC 25 Sep '18

25 Sep '18

#12848: Reduce long-term memory usage of GHCi ---------------------------------------+-------------------------- Reporter: arybczak | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+-------------------------- If you take moderately sized Haskell project (let's use lens as an example) and decide to work with it using `cabal repl`, memory usage of GHCi becomes a bit problematic after a few code reloads. I compared 7.10.3 and 8.0.1 using the following steps: 1. Start GHCi with `cabal repl`. 2. Wait for all modules to load, check memory usage with `htop`. 3. Issue `find . -name '*.hs' -exec touch {} +` in src directory. 4. Issue `:r` in GHCi so it reloads all modules. 5. Repeat (3) and (4) four more times. Results: '''GHC 7.10.3''' * After `cabal repl`: 874MB * After reloading all modules (1st): 1304MB * After reloading all modules (2nd): 1763MB * After reloading all modules (3rd): 2216MB * After reloading all modules (4th): 2672MB * After reloading all modules (5th): 3121MB Basically, every time modules are reloaded memory usage increases by ~450MB, which is definitely not fun. '''GHC 8.0.1''' * After `cabal repl`: 1322MB * After reloading all modules (1st): 2144MB * After reloading all modules (2nd): 2201MB * After reloading all modules (3rd): 2208MB * After reloading all modules (4th): 2212MB * After reloading all modules (5th): 2213MB Here the initial memory usage is much higher as with 7.10.3 and there is a sharp increase after first full reload, but then it more or less plateaus. I presume this change is the result of 6ae616f5be1db6da8bc0c5e36736a76cfea46844 - upfront memory usage is probably higher due to more things being forced (and the fact that memory usage doesn't increase indefinitely is great). However, I'm still concerned about the spike after the first reload - would it be possible to get rid of (or at least decrease) it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees"
by GHC 25 Sep '18

25 Sep '18

#14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | 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: -------------------------------------+------------------------------------- = The basic Ideas Currently GHC uses Augustssons algorithm for pattern matching which was published in 85 which works fine for many cases. However there has been research on how to do better than that for a while now. Most notably by Maranget in "Compiling Pattern Matching to Good Decision Trees". I plan to look into applying his ideas to GHC for my undergraduate thesis. Thanks to imprecise exceptions we should be able to reorder argument evaluation as long as this doesn't make our programs more strict. Proofing that is high on my bucket list but hasn't been done yet. = Pros and Cons **Advantages** would be: * It should lead to equal or better code for the vast majority of patterns. * It might reduce compile times for cases were we can desugar directly to good code. **Disadvantages**: * Desugaring gets more complex. It' obvious that since the underlying algorithm is more complex the desugarer would also grow in complexity in accordance. It is hard to say in advance how much of a difference it will make but I hope it won't be too bad. Depending on the runtime of the new algorithm compared to the old one this might also speed up compilation for cases where the old algorithm generated code that had to be heavily optimized by the simplifier. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14201> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #8578: Improvements to SpinLock implementation
by GHC 25 Sep '18

25 Sep '18

#8578: Improvements to SpinLock implementation ------------------------------------+------------------------------------- Reporter: parcs | Owner: parcs Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The SpinLock implementation has a number of deficiencies. Here is a pair of patches that improves its implementation. Let me know what you think. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8578> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10193: TypeRep Show instance doesn't add parens around type operators
by GHC 24 Sep '18

24 Sep '18

#10193: TypeRep Show instance doesn't add parens around type operators -------------------------------------+------------------------------------- Reporter: | Owner: pawel.nowak | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1-rc3 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: Incorrect result Keywords: | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following code {{{#!hs {-# LANGUAGE AutoDeriveTypeable #-} {-# LANGUAGE TypeOperators #-} import Data.Typeable data a :*: b = Pair a b main = print (typeOf (Pair 'a' 'b')) }}} prints {{{#!hs :*: Char Char }}} which is not valid Haskell. I belive it should print {{{#!hs (:*:) Char Char }}} In my particular case I am using Hint to interpret a type involving type operators. Hint uses showed TypeRep as a type annotation: {{{#!hs let type_str = show $ Data.Typeable.typeOf wit ... let expr_typesig = concat [parens e, " :: ", type_str] }}} What results in a parse error. I can write a patch if someone confirms that's the desired behavior and doesn't break anything. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10193> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15325: Panic in getIdFromTrivialExpr with -fdefer-type-errors
by GHC 23 Sep '18

23 Sep '18

#15325: Panic in getIdFromTrivialExpr with -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: dramforever | 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: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- == Steps to reproduce: Put this in `bug.hs`: (It's a very failed attempt to make a polymorphic list maker function.) {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} module PolyvariadicFunctions where class PolyList e a where polyList :: ([e] -> [e]) -> a -- instance PolyList e [e] where -- polyList dl = dl [] instance (e ~ e2, PolyList e a) => PolyList e (e2 -> a) where polyList dl x = polyList ((x :) . dl) plh :: [Integer] plh = polyList 1 2 3 4 5 }}} Load it in GHCi with `-fdefer-type-errors` to get the following output. Note the 'panic' in the end, and also note that the last `>` line is a no- module-loaded GHCi prompt. The question marks `?` seem to be encoding related and not relevant. This panic not seem to occur with GHC the compiler. The rest of the error messages seem otherwise identical. {{{ GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> :set -fdefer-type-errors Prelude> :l bug.hs [1 of 1] Compiling PolyvariadicFunctions ( bug.hs, interpreted ) bug.hs:17:7: warning: [-Wdeferred-type-errors] ? No instance for (PolyList t0 [Integer]) arising from a use of ‘polyList’ ? In the expression: polyList 1 2 3 4 5 In an equation for ‘plh’: plh = polyList 1 2 3 4 5 | 17 | plh = polyList 1 2 3 4 5 | ^^^^^^^^^^^^^^^^^^ bug.hs:17:16: warning: [-Wdeferred-type-errors] ? No instance for (Num ([t0] -> [t0])) arising from the literal ‘1’ (maybe you haven't applied a function to enough arguments?) ? In the first argument of ‘polyList’, namely ‘1’ In the expression: polyList 1 2 3 4 5 In an equation for ‘plh’: plh = polyList 1 2 3 4 5 | 17 | plh = polyList 1 2 3 4 5 | ^ bug.hs:17:18: warning: [-Wdeferred-type-errors] ? Ambiguous type variable ‘t0’ arising from the literal ‘2’ prevents the constraint ‘(Num t0)’ from being solved. Probable fix: use a type annotation to specify what ‘t0’ should be. These potential instances exist: instance Num Integer -- Defined in ‘GHC.Num’ instance Num Double -- Defined in ‘GHC.Float’ instance Num Float -- Defined in ‘GHC.Float’ ...plus two others (use -fprint-potential-instances to see them all) ? In the second argument of ‘polyList’, namely ‘2’ In the expression: polyList 1 2 3 4 5 In an equation for ‘plh’: plh = polyList 1 2 3 4 5 | 17 | plh = polyList 1 2 3 4 5 | ^ ghc.exe: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-mingw32): getIdFromTrivialExpr case $dNum_a1Be of wild_00 { } Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler\utils\Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler\\coreSyn\\CoreUtils.hs:883:18 in ghc:CoreUtils Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15325> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11155: Trivial error thunk gives "undefined reference to stg_ap_0_upd_info"
by GHC 23 Sep '18

23 Sep '18

#11155: Trivial error thunk gives "undefined reference to stg_ap_0_upd_info" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): | Wiki Page: -------------------------------------+------------------------------------- This error popped up when Alan was coding the solution for #11028. The error is utterly unrelated to what Alan was working on. Here's a reproducer {{{ {-# OPTIONS_GHC -O -fno-full-laziness #-} module Main where foo :: Bool {-# NOINLINE foo #-} foo = error "rk" bar x = let t :: Char t = case foo of { True -> 'v'; False -> 'y' } in [t] main = print (bar ()) }}} Just compile that and you get {{{ Foo.o: In function `c1Sm_info': (.text+0x29a): undefined reference to `stg_ap_0_upd_info' }}} Why do we get that unresolved symbol? The STG code for `bar` looks like {{{ Main.bar :: forall t_aup. t_aup -> [GHC.Types.Char] [GblId, Arity=1, Str=DmdType <L,A>m2, Unf=OtherCon []] = \r srt:SRT:[rf :-> Main.foo] [x_s1RR] let { sat_s1RT [Occ=Once] :: GHC.Types.Char [LclId, Str=DmdType] = \u srt:SRT:[rf :-> Main.foo] [] Main.foo; } in : [sat_s1RT GHC.Types.[]]; }}} Look at that: an updatable thunk saying `sat_s1RT = Main.foo`! The error message is terrible, but the problem is a thunk whose only payload is a single variable. Why does that happen? The Core is {{{ bar = \ (@ t_aup) _ -> let t::Char = case foo of wild_00 { } in : @ Char t ([] @ Char) }}} The `case` is needed to change `foo`'s type from `Bool` to `Char`. The Core-to-STG pass drops the empty case alternatives as useless (rightly), but leaves a bare variable as the RHS, which confuses the code generator. We should clearly substitute `Main.foo` for `t`, either in Core-to-STG, or during code generation. Why hasn't this happened before now? It is quite hard to provoke, because floating the thunk for `t` to top level stops it happening. So it only happens if you switch off full laziness (as my test case here does), or if some very delicate inlining happens after the last float-out. The latter is very rare, but it's what happened to Alan. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11155> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16