GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=!closed&reporter=bos&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=bos&order=priority
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/5289
http://ghc.haskell.org/trac/ghc/ticket/5289#5289: Can't use ghci with a library linked against libstdc++Wed, 29 Jun 2011 04:59:14 GMTbos<p>
My <tt>double-conversion</tt> library links to a C++ library. If I build it and try to use it from <tt>ghci</tt>, I get a failure:
</p>
<pre class="wiki">
Prelude Data.Double.Conversion.Text Data.Text> :m +Data.Double.Conversion.Text Data.Text
Prelude Data.Double.Conversion.Text Data.Text>
Leaving GHCi.
~ $ ghci
GHCi, version 7.0.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :m +Data.Double.Conversion.Text Data.Text
Prelude Data.Double.Conversion.Text Data.Text> toShortest 3
Loading package double-conversion-0.2.0.0 ... can't load .so/.DLL for: stdc++ (libstdc++.so: cannot open shared object file: No such file or directory)
</pre><p>
I can sort of work around this, but then I get a different crash:
</p>
<pre class="wiki">~ $ ln -s /usr/lib64/libstdc++.so.6 libstdc++.so
~ $ LD_LIBRARY_PATH=$(pwd) ghci
GHCi, version 7.0.2: http://www.haskell.org/ghc/ :? for help
Prelude> :m +Data.Double.Conversion.Text Data.Text
Prelude Data.Double.Conversion.Text Data.Text> toShortest 3
Loading package double-conversion-0.2.0.0 ... linking ... done.
"Floating point exception (core dumped)
</pre><p>
Unfortunately, <tt>gdb</tt> doesn't give me a useful stack trace from this :-(
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5289#changelog
http://ghc.haskell.org/trac/ghc/ticket/6166
http://ghc.haskell.org/trac/ghc/ticket/6166#6166: Performance regression in mwc-random since 7.0.xFri, 15 Jun 2012 23:25:16 GMTbos<p>
I've had a report that the performance of the mwc-random package has regressed seriously after upgrading from GHC 7.0 to 7.4. It turns out that 7.2 also has the regression.
</p>
<p>
Here's a sample program.
</p>
<pre class="wiki">import qualified Data.Vector.Unboxed as U
import qualified System.Random.MWC as R
import System.Random.MWC.Distributions (standard)
count = 1000 * 1000
fast gen = standard gen
slow gen = standard gen >>= return
-- Edit this to choose fast or slow.
which gen = slow gen
main = do
gen <- R.create
v <- U.replicateM count (which gen)
print (U.last v)
</pre><p>
With GHC 7.0.3 -O2, this runs in 0.294 sec, regardless of whether <tt>fast</tt> or <tt>slow</tt> is used.
</p>
<p>
Under 7.4, <tt>fast</tt> runs in 0.062 sec (a nice speedup!), but <tt>slow</tt> now takes 9.2 sec (yikes!).
</p>
<p>
Roman suggested compiling the <tt>slow</tt> version with <tt>-fno-state-hack</tt>, which brings performance back up to 0.062 sec.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/6166#changelog
http://ghc.haskell.org/trac/ghc/ticket/7337
http://ghc.haskell.org/trac/ghc/ticket/7337#7337: GHC does not generate great code for bit-level rotationTue, 16 Oct 2012 18:38:46 GMTbos<p>
I'm working on some hashing functions at the moment, and I notice that GHC generates an <tt>or</tt> and a pair of shifts for a rotate. The LLVM back end is smart enough to recover the code's intent via strength reduction and emit a single <tt>rot</tt> instruction, but the regular code generator emits three instructions.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7337#changelog
http://ghc.haskell.org/trac/ghc/ticket/7437
http://ghc.haskell.org/trac/ghc/ticket/7437#7437: peculiar behaviour with default instances and type variablesThu, 22 Nov 2012 00:15:09 GMTbos<p>
Here is a small module that has perplexing behaviour under GHC 7.6.1.
</p>
<p>
In its current form, it compiles and behaves correctly.
</p>
<p>
There are two lines commented out in the module.
</p>
<p>
Uncomment the first type signature for "default put", comment out the second one, and recompile. You'll get an "ambiguous constraint" error.
</p>
<p>
Now uncomment the <tt>FlexibleInstances</tt> pragma. The error changes to "no instance for (Put a0)", and moves to the bottom of the file.
</p>
<p>
I encountered this problem earlier today, in a module (in the binary package) that had <tt>FlexibleInstances</tt> and a default signature where the name of the type variable did not match the name of the class's type variable.
</p>
<p>
In that module, I did not have an instance like the one at the bottom of the file, so the module compiled cleanly and without error.
</p>
<p>
It was not until I tried to compile the module that depended on it that the error occurred. It took me three hours of poking around at random before I accidentally figured out what was wrong.
</p>
<p>
It would be very helpful if GHC either accepted default signatures with non-matching type variables (which seems correct to me) or rejected them, but did one or the other consistently. Finding a mysterious type error in a downstream module because of a very hard-to-spot error in an upstream module turned out to be extremely difficult.
</p>
<pre class="wiki">{-# LANGUAGE DefaultSignatures, FlexibleContexts, DeriveGeneric #-}
-- {-# LANGUAGE FlexibleInstances #-}
module Whee where
import GHC.Generics
class GPut f where
gput :: f a -> [()]
class Put a where
put :: a -> [()]
-- default put :: (Generic t, GPut (Rep t)) => t -> [()]
default put :: (Generic a, GPut (Rep a)) => a -> [()]
put = gput . from
instance GPut U1 where
gput U1 = []
instance GPut a => GPut (M1 i c a) where
gput = gput . unM1
data Foo = Foo
deriving (Generic)
instance Put Foo
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/7437#changelog
http://ghc.haskell.org/trac/ghc/ticket/7944
http://ghc.haskell.org/trac/ghc/ticket/7944#7944: GHC goes into an apparently infinite loop at -O2Wed, 29 May 2013 04:49:24 GMTbos<p>
I ran across a peculiar case this evening: a benchmark that I can't compile with -O2, because GHC goes into an infinite loop.
</p>
<p>
I have a very small repro at <a class="ext-link" href="https://github.com/bos/inttable/blob/2d529c693f4c9a2903dae8f640759a05e7d20c69/Repro.hs"><span class="icon"></span>https://github.com/bos/inttable/blob/2d529c693f4c9a2903dae8f640759a05e7d20c69/Repro.hs</a>
</p>
<p>
You can grab the necessary code and reproduce as follows:
</p>
<pre class="wiki">git clone git://github.com/bos/inttable.git
cd inttable
ghc -O2 --make Repro
</pre><p>
With GHC 7.6.3, this goes into an infinite loop. If I compile with <tt>-v3</tt>, I see that GHC freezes here:
</p>
<pre class="wiki">*** SpecConstr:
Result size of SpecConstr
</pre><p>
This never prints any output. Since the compiler isn't allocating more memory, I assume that it's stuck in a loop, rather than doing something productive.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7944#changelog