April 2018 - ghc-tickets

[GHC] #14987: Memory usage exploding for complex pattern matching
by GHC 17 Apr '18

17 Apr '18

#14987: Memory usage exploding for complex pattern matching -------------------------------------+------------------------------------- Reporter: vmiraldo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 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: -------------------------------------+------------------------------------- It seems like complex pattern matching is consuming a prohibitive amount of memory. From a discussion in ghc-devs, [https://mail.haskell.org/pipermail/ghc-devs/2018-March/015538.html] the exhaustiveness checker could be the culprit. We have tried with 7.10.3, 8.0.2, 8.4.1 and ghc-HEAD. They show similar results. The "-fmax-pmchecker-iterations=0" option seems to help slightly. Bigger cases will run out of memory even with the option enabled. I'm attaching a "minimal" example to help diagnosing. The majority of the code has been generated by Template Haskell. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14987> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5252: UNPACK without optimisation leads to panic
by GHC 17 Apr '18

17 Apr '18

#5252: UNPACK without optimisation leads to panic -------------------------+------------------------------------------------- Reporter: | Owner: (none) simonpj | Type: bug | Status: closed Priority: | Milestone: 7.6.2 normal | Component: | Version: 7.6.1 Compiler | Resolution: | Keywords: fixed | Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Type of failure: | Test Case: deSugar/should_compile/T5252, None/Unknown | T5252Take2 Blocked By: | Blocking: Related Tickets: | -------------------------+------------------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"4a168043f1b584dc201b5af48870ab6498b8a830/ghc" 4a16804/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4a168043f1b584dc201b5af48870ab6498b8a830" Fix markup in the UNPACK pragma section of the user's guide. The ticket 5252 wasn't linked earlier. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5252#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14964: performance regressions from 8.0.2 to 8.4.1
by GHC 17 Apr '18

17 Apr '18

#14964: performance regressions from 8.0.2 to 8.4.1 -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- === Short version: Between 8.0.2 and 8.4.1, compile time without optimization got faster. Compile time with optimization got slightly slower. Performance of generated (optimized) code got significantly slower, and GC productivity went down, despite allocation being about the same. I made this a "task", not a "bug", because there's a ways to go to figure out what is causing this. === Long version, copy and pasted from email to glasgow-haskell-users: I just upgraded from 8.0.2 to 8.4.1, and I took the opportunity to do a few informal compile time and run time tests. There's been a lot of talk about compile time regressions, so maybe these will be of interest, informal as they are. I wound up skipping 8.2.1 due to https://ghc.haskell.org/trac/ghc/ticket/13604, but I could still test with 8.2 perfectly well. Just haven't done it yet. In this context, RunTests is more code with no optimization (and -fhpc, if it matters). debug/seq and opt/seq are the same code but with no optimization and -O respectively. I found that -O2 hurt compile time but didn't improve run time, but it's been a long time so I should run that experiment again. compile times: OS X, macbook pro: {{{ RunTests 549.10s user 118.45s system 343% cpu 3:14.53 total 8.0.2 RunTests 548.71s user 117.10s system 347% cpu 3:11.78 total 8.0.2 RunTests 450.92s user 109.63s system 343% cpu 2:43.13 total 8.4.1 RunTests 445.48s user 107.99s system 341% cpu 2:42.19 total 8.4.1 debug/seq 284.47s user 55.95s system 345% cpu 1:38.58 total 8.0.2 debug/seq 283.33s user 55.27s system 343% cpu 1:38.53 total 8.0.2 debug/seq 220.92s user 50.21s system 337% cpu 1:20.32 total 8.4.1 debug/seq 218.39s user 49.20s system 345% cpu 1:17.47 total 8.4.1 opt/seq 732.63s user 70.86s system 338% cpu 3:57.30 total 8.0.2 opt/seq 735.21s user 71.48s system 327% cpu 4:06.31 total 8.0.2 opt/seq 785.12s user 65.42s system 327% cpu 4:19.84 total 8.4.1 opt/seq 765.52s user 64.01s system 321% cpu 4:18.29 total 8.4.1 }}} Linux, PC: {{{ RunTests 781.31s user 58.21s system 363% cpu 3:50.70 total 8.0.2 RunTests 613.11s user 49.84s system 357% cpu 3:05.52 total 8.4.1 debug/seq 429.44s user 31.34s system 362% cpu 2:07.03 total 8.0.2 debug/seq 329.67s user 23.86s system 352% cpu 1:40.38 total 8.4.1 opt/seq 1277.20s user 45.85s system 358% cpu 6:08.68 total 8.0.2 opt/seq 1339.73s user 39.87s system 341% cpu 6:43.50 total 8.4.1 }}} So it looks like non-optimized compile times have gotten significantly better since 8.0.2. However, optimized has gotten a little worse, but not much. The performance numbers are a bit more disappointing. At first it appeared that allocation went down in 8.4.1 while overall time is up significantly. However, the 8.4.1 used newer dependencies, so to try to control for those, I tested again after using a cabal freeze from the 8.4.1 test. Of course I had to remove the ghc distributed packages, like container and 'ghc' itself, but the rest of the deps should be the same. Those have the 'libs' suffix on Linux. From that, it looks like the improved memory in 8.4.1 was due to external dependencies, and in fact 8.4.1 bumped memory usage up again. Ow. In the graphs, 'score' is just the input file. 'max mb' and 'total mb' and 'prd' come from the post-run GC report, specifically '* bytes maximum residency', '* bytes allocated in the heap', and productivity fields. 'derive', 'lily' and 'perform' are just different kinds of processes. They are CPU time bracketing the specific action, after initialization, and the range is min and max over 6 runs, so no fancy criterion-like analysis. Each run is a separate process, so they should be independent. I was hoping for some gains due to the join points stuff, but it kind of looks like things get worse across the board. I don't know why productivity goes down so much, and I don't know why the effect seems so much worse on OS X. Of course the obvious next step is to see where 8.2.1 lies, but I thought I'd see if there's interest before going to the trouble. Of course, I should track down the regressions for my own purposes, but it's a bit of a daunting task. The step of reducing to a minimal example seems a lot harder for performance than for a bug! Probably some old fashioned SCC annotations await me, but that can be a long and confusing process. OS X, macbook pro: {{{ score max mb total mb prd derive lily perform ghc 6 72.26 3279.22 0.88 0.79~0.84 0.70~0.74 0.31~0.33 8.0.2 6 76.63 3419.20 0.58 1.45~1.59 1.05~1.07 0.33~0.36 8.4.1 bloom 70.69 2456.14 0.89 1.32~1.36 0.15~0.16 8.0.2 bloom 67.86 2589.97 0.62 1.94~1.99 0.20~0.22 8.4.1 cerucuk-punyah 138.01 10080.55 0.93 6.98~7.16 1.24~1.30 8.0.2 cerucuk-punyah 130.78 9617.35 0.68 8.91~9.22 1.57~1.68 8.4.1 hex 32.86 2120.95 0.91 0.76~0.88 0.16~0.19 8.0.2 hex 32.67 2194.82 0.66 1.09~1.16 0.28~0.30 8.4.1 p1 67.01 4039.82 0.92 2.63~2.73 0.47~0.50 8.0.2 p1 64.80 3899.85 0.68 3.35~3.43 0.58~0.59 8.4.1 viola-sonata 69.32 6083.65 0.92 2.48~2.56 2.07~2.13 0.25~0.26 8.0.2 viola-sonata 66.76 6120.26 0.68 3.32~3.43 2.90~2.93 0.32~0.34 8.4.1 }}} Linux, PC: {{{ score max mb total mb prd derive lily perform ghc 6 79.76 3310.69 0.89 0.88~0.89 0.73~0.75 0.27~0.27 8.0.2 6 72.21 3421.45 0.90 0.87~0.87 0.72~0.79 0.28~0.28 8.0.2 libs 6 76.56 3419.05 0.77 1.16~1.17 0.87~0.93 0.33~0.33 8.4.1 bloom 69.82 2461.95 0.89 1.35~1.36 0.17~0.17 8.0.2 bloom 63.45 2554.89 0.90 1.33~1.35 0.18~0.18 8.0.2 libs bloom 67.79 2589.85 0.79 1.64~1.65 0.20~0.20 8.4.1 cerucuk-punyah 137.05 10113.41 0.94 7.44~7.50 1.31~1.33 8.0.2 cerucuk-punyah 128.09 10278.03 0.94 7.50~7.55 1.37~1.38 8.0.2 libs cerucuk-punyah 131.20 9617.22 0.84 7.35~7.40 1.49~1.50 8.4.1 hex 32.02 2096.87 0.92 0.73~0.74 0.18~0.18 8.0.2 hex 32.05 2200.30 0.91 0.73~0.80 0.19~0.19 8.0.2 libs hex 32.46 2144.22 0.83 0.89~0.90 0.20~0.20 8.4.1 p1 65.88 4054.66 0.93 2.84~2.87 0.49~0.50 8.0.2 p1 62.60 4127.68 0.94 2.83~2.92 0.51~0.51 8.0.2 libs p1 64.72 3899.72 0.81 2.80~2.81 0.54~0.55 8.4.1 viola-sonata 68.68 6086.49 0.93 2.55~2.56 2.10~2.12 0.27~0.27 8.0.2 viola-sonata 65.05 6212.57 0.93 2.52~2.55 2.07~2.16 0.28~0.28 8.0.2 libs viola-sonata 66.85 6120.15 0.83 2.91~2.92 2.48~2.51 0.30~0.31 8.4.1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14964> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
by GHC 17 Apr '18

17 Apr '18

#4245: ghci panic: thread blocked indefinitely in an MVar operation -------------------------------+-------------------------------------- Reporter: pturnbull | Owner: tibbe Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 6.12.3 Resolution: fixed | Keywords: MVar Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 Comment: Alright, then let's go ahead and close it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4245#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2805: Test ffi009(ghci) fails on PPC Mac OS X
by GHC 17 Apr '18

17 Apr '18

#2805: Test ffi009(ghci) fails on PPC Mac OS X -------------------------------------+------------------------------------- Reporter: thorkilnaur | Owner: (none) Type: bug | Status: closed Priority: lowest | Milestone: Component: Runtime System | Version: 6.11 (Linker) | Resolution: wontfix | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Test Case: ffi009(ghci) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix Comment: Yes, I think so. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2805#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5129: "evaluate" optimized away
by GHC 17 Apr '18

17 Apr '18

#5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: seq, evaluate Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Phab:D615, Wiki Page: | Phab:D4514 -------------------------------------+------------------------------------- Comment (by bgamari): George, indeed we do. Alp has recently been working on cleaning up the `./validate --slow` output (#14890) so we can run it during CI. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5129#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15047: Outdated comments in RnSource.hs
by GHC 17 Apr '18

17 Apr '18

#15047: Outdated comments in RnSource.hs -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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): Phab:D4596 | Wiki Page: -------------------------------------+------------------------------------- While reading sources of the Renamer I noticed some comments which seem to be irrelevant now. The body of `rnSrcDecls` (`RnSource.hs`) is broken up in several “parts” (A, B, etc.). #b1884b0e6 removed what is used to be called part (C) — the use of `extendRecordFieldEnv`, with the following comment in Phab:D761: > Get rid of `extendRecordFieldEnv`, do it in `getLocalNonValBinders` instead (Note: `getLocalNonValBinders` belongs to part (B)). At the same time, the references to this part (C) remained in comments to other "parts" (B and D2). Removing these references will save inexperienced reader from confusion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15047> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15046: Broken links on haskell.org/ghc
by GHC 17 Apr '18

17 Apr '18

#15046: Broken links on haskell.org/ghc -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Trac & Git | 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: -------------------------------------+------------------------------------- [https://www.haskell.org/ghc/ haskell.org/ghc] has broken links in the menu (sidebar on the left). The ones concerning Track: * Report a bug * Request a feature * Developers (Wiki) All point to Hackage for some reason. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15046> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #1290: ghc runs preprocessor too much
by GHC 17 Apr '18

17 Apr '18

#1290: ghc runs preprocessor too much -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.7 Resolution: | Keywords: cpp Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: 14553 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1290#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7842: Incorrect checking of let-bindings in recursive do
by GHC 17 Apr '18

17 Apr '18

#7842: Incorrect checking of let-bindings in recursive do -------------------------------------+------------------------------------- Reporter: diatchki | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: RecursiveDo 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => RecursiveDo -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7842#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0