[GHC] #11161: New exhaustiveness checker breaks concurrent/prog001

GHC ghc-devs at haskell.org
Fri Dec 4 01:44:01 UTC 2015


#11161: New exhaustiveness checker breaks concurrent/prog001
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:  gkaracha
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.0.1
       Component:  Compiler          |              Version:  7.10.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Compile-time      |            Test Case:
  performance bug                    |  concurrent/prog001
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by bgamari):

 * cc: gkaracha (added)
 * owner:   => gkaracha


Old description:

> The new exhaustiveness checker appears to allocate until the machine runs
> out of memory while compiling the `concurrent/prog001` testcase. In
> particular it stalls while desugaring the `Thread` module. The fact that
> this module contains non-trivial pattern matching, coupled with the
> compiler gets stuck in `Desugar`, and the fact that I've noted other
> performance issues with the new exhaustiveness checker (see #10711) leads
> me to believe that this patch is to blame.

New description:

 The new exhaustiveness checker appears to allocate until the machine runs
 out of memory while compiling the `concurrent/prog001` testcase. In
 particular it stalls while desugaring the `Thread` module. The fact that
 this module contains non-trivial pattern matching, coupled with the
 compiler gets stuck in `Desugar`, and the fact that I've noted other
 performance issues with the new exhaustiveness checker (see #11160) leads
 me to believe that this patch is to blame.

--

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11161#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list