January 2018 - ghc-tickets

[GHC] #14703: T14507 testcase fragile due to unique exposed in error message
by GHC 22 Jan '18

22 Jan '18

#14703: T14507 testcase fragile due to unique exposed in error message -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.4.1-alpha1 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 noticed this failure in the CircleCI output: {{{#!patch --- ./patsyn/should_fail/T14507.run/T14507.stderr.normalised 2018-01-22 18:57:32.381575253 +0000 +++ ./patsyn/should_fail/T14507.run/T14507.comp.stderr.normalised 2018-01-22 18:57:32.381575253 +0000 @@ -2,7 +2,7 @@ T14507.hs:18:9: Iceland Jack! Iceland Jack! Stop torturing me! Pattern-bound variable x :: TypeRep a - has a type that mentions pattern-bound coercion: co_a2CF + has a type that mentions pattern-bound coercion: co_a2D4 Hint: use -fprint-explicit-coercions to see the coercions Probable fix: add a pattern signature In the declaration for pattern synonym ‘SO’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14703> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14678: GHc 8.4.1-alpha's bundled transformers doesn't correspond to a tagged release
by GHC 22 Jan '18

22 Jan '18

#14678: GHc 8.4.1-alpha's bundled transformers doesn't correspond to a tagged release -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 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 8.4.1-alpha claims to be bundled with `transformers-0.5.4.0`, but this isn't true. That's because it's using `transformers` commit http://git.haskell.org/packages/transformers.git/commit/36311d39bc545261dab…, which happened somewhere in between the `0.5.4.0` and `0.5.5.0` releases. This is actually a problem for me in practice because that commit gives a `Semigroup` instance for `Constant` which should have only been introduced in `0.5.5.0`, according to the [https://hackage.haskell.org/package/transformers-0.5.5.0/changelog changelog]. But commit 36311d39bc545261dab85d4a27af562db1868ed6 uses version `0.5.4.0`, which makes it impossible to guard against the existence of this instance using CPP (see [https://travis-ci.org/ekmett /transformers-compat/jobs/329285046#L739 this Travis build failure] for an example of this problem occurring). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14678> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #6087: Join points need strictness analysis
by GHC 22 Jan '18

22 Jan '18

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): osa1, can you take care of this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA
by GHC 22 Jan '18

22 Jan '18

#14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: https://github.com/ntc2/ghc-8.2.1 | -regex-lazy-text-bug | Blocking: | Related Tickets: 13745 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using `Text.RE.TDFA` from the regex-tdfa package on GHC 8.2 to match trivial regexes against `Data.Text.Lazy` strings, I see **exponential runtime**. On GHC 8.0, or using `Data.Text` strict strings or `String` strings, the runtime is as expected. Here's my repo with simple test code illustrating the regression and timing stats: https://github.com/ntc2/ghc-8.2.1-regex-lazy-text-bug. In summary, for the problematic combination of GHC version and libraries, the run times are 3s, 10s, 22s, and 40s for counting regex matches in files with 10000, 20000, 30000, and 40000 lines, respectively. For all of the unproblematic combinations -- i.e. GHC 8.0.2, `String`, strict `Data.Text`, or building with profiling -- the run time is always about 1s! And **this is a Heisenbug**, in that the performance problem goes away if I build with profiling support! There is the separate Issue #13745 about **compile-time regressions** in GHC 8.2 + the regex-tdfa package, that [https://ghc.haskell.org/trac/ghc/ticket/13745#comment:18 I commented on]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14519> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 50

[GHC] #13891: forkIO can trivially defeat bracket
by GHC 22 Jan '18

22 Jan '18

#13891: forkIO can trivially defeat bracket -------------------------------------+------------------------------------- Reporter: bgamari | 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 this program, {{{#!hs import Control.Concurrent import Control.Exception main = do putStrLn "forking" forkIO $ bracket (putStrLn "forked") (const $ putStrLn "finalize") (const $ putStrLn "hello" >> threadDelay 100000000) threadDelay 10000 putStrLn "done" }}} Would you predict that it would print `finalize`? Answer: no. It will print, {{{ forking forked hello done }}} It would pointed out by an author of a cryptographic library (`raaz`) that this is quite bad as it means that secure memory could leak out uncleared. It's not entirely clear how best to deal with this. Perhaps raise a `ThreadKilled` async exception to all running threads during RTS shutdown, followed by a synchronization? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13891> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14700: ApplicativeDo in MonadComprehensions
by GHC 22 Jan '18

22 Jan '18

#14700: ApplicativeDo in MonadComprehensions -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- It appears that a MonadComp (even one that is "Applicative only") is not transformed appropriately in the presence of ApplicativeDo. {{{#!hs {-# LANGUAGE MonadComprehensions #-} {-# LANGUAGE ApplicativeDo #-} value1 = [ f a b c | a <- ma, b <- mb, c <- mc ] value2 = do { a <- ma; b <- mb; c <- mc; return (f a b c) } value3 = f <$> ma <*> mb <*> mc }}} value1 should desugar to value2 via monadcomp and to value3 via appdo. Yet I observe very bad performance in some specific instance (due to a slower Monad instance) when using value1, where value2 and value3 have good performance. I have not looked at desuraged/core dumps but the observation seems clear. Tested on ghc-8.0.2 only. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14700> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14667: Compiling a function with a lot of alternatives bottlenecks on insertIntHeap
by GHC 22 Jan '18

22 Jan '18

#14667: Compiling a function with a lot of alternatives bottlenecks on insertIntHeap -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- I have a module that looks like this: {{{ module A10000 where data A = A | A00001 | A00002 ... | A10000 f :: A -> Int f A00001 = 19900001 f A00002 = 19900002 ... f A10000 = 19910000 }}} Compiling with `-s` gives: {{{ [1 of 1] Compiling A10000 ( A10000.hs, A10000.o ) A10000.hs:10004:1: warning: Pattern match checker exceeded (2000000) iterations in an equation for ‘f’. (Use -fmax-pmcheck-iterations=n to set the maximun number of iterations to n) | 10004 | f A00001 = 19900001 | ^^^^^^^^^^^^^^^^^^^... 95,068,628,968 bytes allocated in the heap 14,166,421,680 bytes copied during GC 312,247,488 bytes maximum residency (19 sample(s)) 3,267,024 bytes maximum slop 857 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 35163 colls, 0 par 5.191s 5.170s 0.0001s 0.0724s Gen 1 19 colls, 0 par 1.240s 1.236s 0.0650s 0.1872s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.000s ( 0.000s elapsed) MUT time 23.100s ( 23.341s elapsed) GC time 6.431s ( 6.405s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.000s ( 0.001s elapsed) Total time 29.532s ( 29.748s elapsed) }}} With profiling enabled I get: {{{ total time = 22.67 secs (22673 ticks @ 1000 us, 1 processor) total alloc = 36,143,653,320 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc ticks bytes insertIntHeap Hoopl.Dataflow compiler/cmm/Hoopl/Dataflow.hs:(450,1)-(454,38) 73.9 77.5 16746 28001680176 SimplTopBinds SimplCore compiler/simplCore/SimplCore.hs:770:39-74 9.4 1.8 2136 647116224 deSugar HscMain compiler/main/HscMain.hs:511:7-44 2.6 4.2 599 1530056552 pprNativeCode AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(529,37)-(530,65) 2.3 2.9 524 1030493864 StgCmm HscMain compiler/main/HscMain.hs:(1426,13)-(1427,62) 1.3 1.4 288 497401376 RegAlloc-linear AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(658,27)-(660,55) 0.9 1.1 201 383789200 tc_rn_src_decls TcRnDriver compiler/typecheck/TcRnDriver.hs:(494,4)-(556,7) 0.8 1.2 176 441973152 Parser HscMain compiler/main/HscMain.hs:(316,5)-(384,20) 0.5 1.1 113 411448880 }}} After a local patch that basically reverts https://phabricator.haskell.org/rGHC5a1a2633553 I get: {{{ [1 of 1] Compiling A10000 ( A10000.hs, A10000.o ) A10000.hs:10004:1: warning: Pattern match checker exceeded (2000000) iterations in an equation for ‘f’. (Use -fmax-pmcheck-iterations=n to set the maximun number of iterations to n) | 10004 | f A00001 = 19900001 | ^^^^^^^^^^^^^^^^^^^... 15,162,268,144 bytes allocated in the heap 4,870,184,600 bytes copied during GC 323,794,936 bytes maximum residency (19 sample(s)) 3,074,056 bytes maximum slop 886 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 811 colls, 0 par 1.828s 1.821s 0.0022s 0.0770s Gen 1 19 colls, 0 par 1.217s 1.213s 0.0638s 0.1820s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.000s ( 0.000s elapsed) MUT time 5.842s ( 6.144s elapsed) GC time 3.046s ( 3.034s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.000s ( 0.001s elapsed) Total time 8.888s ( 9.179s elapsed) }}} For a file of smaller size with 1000 constructors, it still gives a 10% win. This example is artificial, but it looks like something that someone could write for a sparse enum that looks like this in C++: {{{ enum access_t { read = 1, write = 2, exec = 4 }; }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14667> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Re: [GHC] #2988: Improve float-in
by GHC 22 Jan '18

22 Jan '18

#2988: Improve float-in -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.10.1 Resolution: | Keywords: FloatInwards 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => FloatInwards Comment: No it's not fixed. Here's a concrete test case {{{ module T2988 where foo :: Int -> Bool -> String foo y b = let x1 = y+1 x2 = x1 : [] x3 = 1 : x2 x4 = 2 : x3 x5 = 3 : x4 x6 = 4 : x5 in case b of True -> show x6 False -> show (reverse x6) }}} We get a cascade of one-at-a-time inlinings. Horrid. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2988#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6087: Join points need strictness analysis
by GHC 22 Jan '18

22 Jan '18

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Huh. We have a flag `-flate-dmd-anal`, but it does not seem to be enabled by `-O` or `-O2`. Could someone do a nofib run to see if it makes a difference? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14692: Deriving Show with -XEmptyDataDeriving cases on the wrong argument
by GHC 22 Jan '18

22 Jan '18

#14692: Deriving Show with -XEmptyDataDeriving cases on the wrong argument -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 Keywords: deriving | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running this program in GHC 8.4.1-alpha: {{{#!hs {-# LANGUAGE EmptyDataDeriving #-} {-# OPTIONS_GHC -ddump-deriv #-} module Main (main) where data Empty deriving Show loop :: Empty loop = let x = x in x main :: IO () main = print loop }}} One would expect this to loop infinitely at runtime, but in practice, that is not the case: {{{ $ /opt/ghc/8.4.1/bin/runghc Bug.hs ==================== Derived instances ==================== Derived class instances: instance GHC.Show.Show Main.Empty where GHC.Show.showsPrec z_a1Iu = case z_a1Iu of Derived type family instances: ==================== Filling in method body ==================== GHC.Show.Show [Main.Empty] GHC.Show.show = GHC.Show.$dmshow @(Main.Empty) ==================== Filling in method body ==================== GHC.Show.Show [Main.Empty] GHC.Show.showList = GHC.Show.$dmshowList @(Main.Empty) Bug.hs: Bug.hs:5:21-24: Non-exhaustive patterns in case }}} The `-ddump-deriv` output reveals why: the `showsPrec` implementation for `Empty` is casing on the //precedence// argument, not the actual value of type `Empty`! This results in the non-exhaustive patterns error. This is my fault, so I'll prepare a fix :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14692> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3