#11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10527 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by jberryman: Old description:
This is perhaps the same bug as #10527 but I'm not sure, as it goes away with a modest bump to `-fsimpl-tick-factor`.
I'm developing a library and am seeing this when I go to compile a small hello-world executable.
{{{ <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $fMonadIdentity_$c>>= To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 6642 }}}
If I remove the `INLINE` from the exported functions it goes away, but also makes the code much slower (for some reason the way I use the function in my benchmark suite doesn't exhibit the error).
It also compiles with `-fsimpl-tick-factor=200`.
Previously on 7.10.1 I got the same error in a different part of my code (the test suite) which went away when I moved to 7.10.3. If it's helpful I can upload the state of the repo, but it's not a small test case.
Even if this is a duplicate, I'd love some guidance on this: Is this actually a ghc bug, or is it my fault that I've got too much inlining in my code (I've never seen anything like this before, and pretty much mark everything INLINE)? Should I pass this off to my users and should it be their responsibility to bump `-fsimpl-tick-factor` to work around regressions in their GHC? If I want to try to work around this in my library, what strategies could I employ (besides disabling inlining of exported functions)?
New description: This is perhaps the same bug as #10527 but I'm not sure, as it goes away with a modest bump to `-fsimpl-tick-factor`. I'm developing a library and am seeing this when I go to compile a small hello-world executable. {{{ <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $fMonadIdentity_$c>>= To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 6642 }}} If I remove the `INLINE` from the exported functions it goes away, but also makes the code much slower (for some reason the way I use the function in my benchmark suite doesn't exhibit the error). It also compiles with `-fsimpl-tick-factor=200`. Previously on 7.10.1 I got the same error in a different part of my code (the benchmark suite) which went away when I moved to 7.10.3. If it's helpful I can upload the state of my library repo, but it's not a small test case. Even if this is a duplicate, I'd love some guidance on this: Is this actually a ghc bug, or is it my fault that I've got too much inlining in my code (I've never seen anything like this before, and pretty much mark everything INLINE)? Should I pass this off to my users and should it be their responsibility to bump `-fsimpl-tick-factor` to work around regressions in their GHC? If I want to try to work around this in my library, what strategies could I employ (besides disabling inlining of exported functions), and how do I know whether this won't blow up in the same way for users anyway? -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11263#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler