GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=!closed&reporter=blitzcode&order=priority
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?status=!closed&reporter=blitzcode&order=priority
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/8331
http://ghc.haskell.org/trac/ghc/ticket/8331#8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasonsThu, 19 Sep 2013 16:31:42 GMTblitzcode<p>
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.
</p>
<p>
This is the small test case I wrote to understand the problem better:
</p>
<pre class="wiki">{-# 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
</pre><p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
In any case, once the specialization is applied in my actual program, the following error appears:
</p>
<pre class="wiki">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
</pre><p>
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.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8331#changelog
http://ghc.haskell.org/trac/ghc/ticket/8511
http://ghc.haskell.org/trac/ghc/ticket/8511#8511: GHCi Startup Crash with GHC 7.6.3 / HP 2013.2.0.0 64bit on OS X 10.6Sat, 09 Nov 2013 10:16:43 GMTblitzcode<p>
A couple of HP / GHC releases later this bug still seems to exist:
</p>
<p>
<a class="ext-link" href="http://ghc.haskell.org/trac/ghc/ticket/6138"><span class="icon"></span>http://ghc.haskell.org/trac/ghc/ticket/6138</a>
</p>
<p>
32bit works fine, 64bit GHCi crashes frequently on startup, even with XCode 4.1 installed.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8511#changelog
http://ghc.haskell.org/trac/ghc/ticket/8517
http://ghc.haskell.org/trac/ghc/ticket/8517#8517: Add library function retrieve label set by GHC.Conc.Sync.labelThreadSat, 09 Nov 2013 21:00:09 GMTblitzcode<p>
It would be useful to be able to retrieve the label set by the labelThread function. For instance, a logging / tracing system could output a human readable string for the thread the trace originated from instead of just the thread ID.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8517#changelog
http://ghc.haskell.org/trac/ghc/ticket/8676
http://ghc.haskell.org/trac/ghc/ticket/8676#8676: RTS headers don't compile as C++Fri, 17 Jan 2014 16:51:08 GMTblitzcode<p>
GHC's RTS headers can't be included from C++, as they contain constructs like this
</p>
<pre class="wiki">dbl_link_replace(bdescr *new, bdescr *old, bdescr **list)
</pre><p>
(notice the 'new'). This is the case for the headers shipped with 7.6.3 and still seems to be in the HEAD version.
</p>
<p>
Since the code has the usual
</p>
<pre class="wiki">#ifdef __cplusplus
extern "C" {
#endif
</pre><p>
all over the place, I assume the C++ incompatibility is simply an oversight? In any case, it would seem highly unusual to have a C interface that can't be consumed from C++. It seems all the incompatibilities could be removed with at worst a small amount of inconvenience, and automatic checking for C++ compatibility on each build could be added.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8676#changelog