7.10.1.20150612 It's very sensitive, I see today. Sometimes it fails with Simplifier ticks exhausted other times it works. Bizarre I think the latter is the more common case and I think the former case has something to do with existing .o file or order of args and -fforce-recomp may mean it always works but that is very speculative. The two casesor $ time ghc -fno-specialise -O2 Slice.hs [1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs, Slice.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150612 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $j_s1FS5 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: 1668604 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug real 0m19.714s user 0m18.264s sys 0m0.875s $ time ghc -O2 -fno-specialise Slice.hs [1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs, Slice.o ) real 0m3.228s user 0m3.040s sys 0m0.155s On Sat, Jun 20, 2015 at 2:03 PM, GHC wrote:

#10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+-------------------------------------

Comment (by bgamari):

George, what GHC version did you test `-fno-specialise` on? While yesterday I was able to confirm that `-fno-specialise` seemed to make no difference on a test machine running what should have been 7.10.1 I am now having trouble replicating this on my laptop. Unfortunately I no longer have access to the test environment on which I tested this yesterday but clearly something was inconsistent.

I am now seeing on multiple machines that `-fno-specialise` indeed allows things to compile, {{{ $ ghc -V The Glorious Glasgow Haskell Compilation System, version 7.10.1 $$ time ghc Slice.hs -fforce-recomp -O2 -fno-specialise [1 of 1] Compiling Slice ( Slice.hs, Slice.o )

real 0m3.759s user 0m1.688s sys 0m0.044s $ time ghc Slice.hs -fforce-recomp -O2 [1 of 1] Compiling Slice ( Slice.hs, Slice.o ) ^C

real 0m51.103s user 0m44.336s sys 0m0.948s }}}

I am now looking at whether disabling only cross-module specialisation is enough to eliminate the blow-up.

-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10491#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler