#5448: GHC stuck in infinite loop compiling with optimizations
---------------------------------+------------------------------------------
Reporter: ronwalf | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.0.3
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: | Os: MacOS X
Blocking: | Architecture: x86_64 (amd64)
Failure: Compile-time crash |
---------------------------------+------------------------------------------
Changes (by simonpj):
* status: closed => new
* resolution: wontfix =>
Comment:
Ron writes: There are now three more examples, at least two of which
weren't 'contrived':
* #5448
* #5400
* #3872
It took me about 4-6 hours to track down this bug in my own code
(#5448) since it required repeatedly bisecting a larger program until I
had a small testcase. In the test program, I can get around it with `{-#
NOINLINE funcEq #-}`. In the program it came from, though, `FuncEq` is an
imported value, so I have to either compile with `-O0`, or change put the
pragma in the imported library, where it will effect a fair amount of code
that ''doesn't'' hit this bug.
If adding the check is too expensive, can the inliner have a configurable
recursion count (ala `-fcontext-stack`)?
''Simon responds'': it's not that it's too expensive, more that I don't
know a way to prevent divergence that isn't so conservative that it
hobbles regular optimisation. Actually our new paper (Haskell Symposium
2011) "Termination combinators forever" may show the way -- but that will
be expensive.
A count sounds like a reasonable idea; it would at least stop the compiler
falling into an infinite loop.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5448#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
