August 2014 - ghc-tickets

[GHC] #9403: Make --show-iface more human readable
by GHC 04 Aug '14

04 Aug '14

#9403: Make --show-iface more human readable -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Right now --show-iface is not particularly interpretable, even if you are looking at the Outputable instance for `ModIface`. The problem seems to be the output for `mi_deps`, `mi_usages`, `mi_decls`, `mi_insts`, `mi_fam_insts` and `mi_rules` is not clearly delimited, making it unclear (for example) what `import -/ base:Prelude HASH` refers to unless you already happen to know that this must be from `mi_usages`. It should be relatively easy to improve this, but I want to make sure people who rely on this output aren't blindsided by the changes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9403> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #9401: MVar deadlock exceptions cause exceptions in later MVar ops
by GHC 04 Aug '14

04 Aug '14

#9401: MVar deadlock exceptions cause exceptions in later MVar ops -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: invalid | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => invalid Comment: This isn't a bug. There are two threads: the main thread, blocked in readMVar, and the child thread, blocked in takeMVar. BOTH threads are deadlocked, so the RTS sends them both an exception. It has no way to tell that unblocking the child thread would later allow the main thread to make progress, or indeed whether the reverse might be true. So the rule is simple: when there are a group of deadlocked threads, they are all sent an exception simultaneously. There's a similar example in my book, [http://chimera.labs.oreilly.com/books/1230000000929/ch15.html#sec_deadlock] see `deadlock1.hs`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9401#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7662: Improve GC of mutable objects
by GHC 03 Aug '14

03 Aug '14

#7662: Improve GC of mutable objects -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Milestone: ⊥ Priority: normal | Version: 7.7 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ihameed): * cc: idhameed@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7662#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2867: Make a way to tell GHC that a pragma name should be "recognised"
by GHC 03 Aug '14

03 Aug '14

#2867: Make a way to tell GHC that a pragma name should be "recognised" -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.10.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by agdfrnd): * owner: agdfrnd => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2867#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2867: Make a way to tell GHC that a pragma name should be "recognised"
by GHC 02 Aug '14

02 Aug '14

#2867: Make a way to tell GHC that a pragma name should be "recognised" -------------------------------------+------------------------------------- Reporter: igloo | Owner: agdfrnd Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.10.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by agdfrnd): * owner: => agdfrnd * failure: => None/Unknown * type: bug => feature request -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2867#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8880: Configured gcc not used for some build steps
by GHC 02 Aug '14

02 Aug '14

#8880: Configured gcc not used for some build steps ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The gcc passed to `./configure --with-gcc` isn't used for all gcc invocations, leadings to warnings (and potentially problems) on OS X where the default gcc is llvm. Here's an example, the call to `gcc -E` doesn't use my configure gcc, `/usr/local/bin/gcc-4.9`: {{{ sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.dyn_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.l_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.debug_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_debug_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_l_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.debug_dyn_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_dyn_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_debug_dyn_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.l_dyn_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_l_dyn_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && true gcc -E -m64 -DPROFILING -DTHREADED_RTS -DDEBUG -Irts/dist/build -m64 -fno-stack-protector -Wall -Wextra -Wstrict-prototypes -Wmissing- prototypes -Wmissing-declarations -Winline -Waggregate-return -Wpointer- arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -fno-strict- aliasing -fno-common -DDTRACE -O2 -fomit-frame-pointer -DRtsWay=\"rts_v\" -Wno-strict-prototypes -MM -x c rts/WSDeque.c -MF rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit no checking for sigaction... In file included from rts/WSDeque.c:44: In file included from rts/RtsUtils.h:12: rts/BeginPrivate.h:9:13: warning: unknown pragma ignored [-Wunknown- pragmas] #pragma GCC visibility push(hidden) ^ In file included from rts/WSDeque.c:44: In file included from rts/RtsUtils.h:48: rts/EndPrivate.h:2:13: warning: unknown pragma ignored [-Wunknown-pragmas] #pragma GCC visibility pop ^ 2 warnings generated. }}} I can't quite tell from which part of the build this is. Looks RTS related. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8880> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9397: Probable fix: add an INLINE[n] or NOINLINE[n] pragma confused?
by GHC 02 Aug '14

02 Aug '14

#9397: Probable fix: add an INLINE[n] or NOINLINE[n] pragma confused? -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | warning at compile-time Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Building ghc HEAD using 7.8.3 under OS X results in the following warnings: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -package-name binary-0.7.1.0 -hide-all-packages -i -ilibraries/binary/src -ilibraries/binary/dist-install/build -ilibraries/binary/dist- install/build/autogen -Ilibraries/binary/dist-install/build -Ilibraries/binary/dist-install/build/autogen -Ilibraries/binary/. -optP-DGENERICS -optP-include -optPlibraries/binary/dist- install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.1.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -O2 -Wall -fliberate-case-threshold=1000 -XHaskell98 -O2 -no-user-package-db -rtsopts -odir libraries/binary/dist-install/build -hidir libraries/binary/dist-install/build -stubdir libraries/binary/dist- install/build -split-objs -dynamic-too -c libraries/binary/src/Data/Binary/Get/Internal.hs -o libraries/binary/dist- install/build/Data/Binary/Get/Internal.o -dyno libraries/binary/dist- install/build/Data/Binary/Get/Internal.dyn_o libraries/binary/src/Data/Binary/Get/Internal.hs:314:1: Warning: Rule "<$> to <*>" may never fire because ‘<$>’ might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ‘<$>’ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -package-name binary-0.7.1.0 -hide-all-packages -i -ilibraries/binary/src -ilibraries/binary/dist-install/build -ilibraries/binary/dist- install/build/autogen -Ilibraries/binary/dist-install/build -Ilibraries/binary/dist-install/build/autogen -Ilibraries/binary/. -optP-DGENERICS -optP-include -optPlibraries/binary/dist- install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.1.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -O2 -Wall -fliberate-case-threshold=1000 -XHaskell98 -O2 -no-user-package-db -rtsopts -odir libraries/binary/dist-install/build -hidir libraries/binary/dist-install/build -stubdir libraries/binary/dist- install/build -split-objs -dynamic-too -c libraries/binary/src/Data/Binary/Get.hs -o libraries/binary/dist- install/build/Data/Binary/Get.o -dyno libraries/binary/dist- install/build/Data/Binary/Get.dyn_o libraries/binary/src/Data/Binary/Get.hs:416:1: Warning: Rule "getWord8/readN" may never fire because ‘getWord8’ might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ‘getWord8’ libraries/binary/src/Data/Binary/Get.hs:417:1: Warning: Rule "getWord16be/readN" may never fire because ‘getWord16be’ might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ‘getWord16be’ libraries/binary/src/Data/Binary/Get.hs:418:1: Warning: Rule "getWord16le/readN" may never fire because ‘getWord16le’ might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ‘getWord16le’ libraries/binary/src/Data/Binary/Get.hs:419:1: Warning: Rule "getWord32be/readN" may never fire because ‘getWord32be’ might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ‘getWord32be’ libraries/binary/src/Data/Binary/Get.hs:420:1: Warning: Rule "getWord32le/readN" may never fire because ‘getWord32le’ might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ‘getWord32le’ libraries/binary/src/Data/Binary/Get.hs:421:1: Warning: Rule "getWord64be/readN" may never fire because ‘getWord64be’ might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ‘getWord64be’ libraries/binary/src/Data/Binary/Get.hs:422:1: Warning: Rule "getWord64le/readN" may never fire because ‘getWord64le’ might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ‘getWord64le’ }}} Not sure what the probable fix is suggesting as the functions that are pointed are already marked as INLINE. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9397> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons
by GHC 01 Aug '14

01 Aug '14

#8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons -------------------------+------------------------------------------------- Reporter: | Owner: blitzcode | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- I encountered a 'RULE left-hand side too complicated to desugar' warning when trying to reduce some typeclass overhead through a SPECIALIZE pragma. The change I had to make to my program to make the warning go away seems rather strange, so I thought it might be worth reporting as a bug. This is the small test case I wrote to understand the problem better: {{{ {-# LANGUAGE FlexibleInstances, RankNTypes #-} module Main (main) where import Control.Monad import Control.Monad.Reader import Control.Monad.ST import Control.Applicative class (Applicative m, {- Functor m ,-} Monad m) => MonadAbstractIOST m where addstuff :: Int -> m Int type ReaderST s = ReaderT (Int) (ST s) instance MonadAbstractIOST (ReaderST s) where addstuff a = return . (a +) =<< ask runAbstractST :: (forall s. ReaderST s a) -> a runAbstractST f = runST $ runReaderT f 99 {-# SPECIALIZE INLINE useAbstractMonad :: ReaderST s Int #-} useAbstractMonad :: MonadAbstractIOST m => m Int useAbstractMonad = foldM (\a b -> a `seq` return . (a +) =<< (addstuff b)) 0 [1..50000000] -- useConcreteMonad :: ReaderST s Int -- useConcreteMonad = foldM (\a b -> a `seq` return . (a +) =<< (addstuff b)) 0 [1..50000000] main :: IO () main = do let st = runAbstractST useAbstractMonad putStrLn . show $ st }}} The use case here is simply having a library of functions which are abstracted from the underlying implementation of state (Reader / IO, Reader / ST, etc.) and operate on it with a small set of typeclass functions. This has very severe runtime overhead (~5x) compared to using the actual transformer stack directly, so a SPECIALIZE pragma seemed a good idea. The simple program above works as expected, but the warning appears as soon as the 'Functor' superclass is commented back in. It seems to me this should make no difference as Functor is already a superclass of Applicative. It was still there simply by oversight. I think SPECIALIZE should not fail in this case, and if it does, it would be really helpful to have a better error message. 'Too complicated' does not help in tracking down what needs to be changed for the specialization to happen, and given how harsh the overhead is otherwise, this is quite painful. In any case, once the specialization is applied in my actual program, the following error appears: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone a_saCf{v} [lid] 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: 66169 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It seems like I need a -fsimpl-tick-factor of 450-500 for the compilation to succeed, resulting in a ~3x increase in binary size and a ~4x increase in compile time. The resulting code at least seems to benefit from the specialization as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8331> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8