GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&type=bug&order=owner
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&type=bug&order=owner
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/5645
http://ghc.haskell.org/trac/ghc/ticket/5645#5645: Sharing across functions causing space leakThu, 17 Nov 2011 17:20:35 GMTtener<p>
I have two test functions in code that both have a lazy list declared like this:
</p>
<pre class="wiki"> let elements = [0 .. someBigInt]
</pre><p>
If, from main, I run both of them, the compiler decides to share this list among them. In effect the memory is exhausted.
</p>
<p>
If only one function is called, the memory used is constant and low.
</p>
<p>
The workaround is to declare on of them like this:
</p>
<pre class="wiki"> let elements = [0] ++ [1 .. someBigInt]
</pre><p>
But this is very ugly.
</p>
<p>
What worries me most is that this is very non-obvious behaviour: if the list is declared locally inside a function, the compiler shouldn't (?) share it between two functions. It feels wrong.
</p>
<p>
If one of the functions is declared in different module, this behavior disappears. Seems like CSE is not done across modules boundaries.
</p>
<p>
Another workaround (tested) is to disable CSE with -fno-cse switch. You can test it works with "make workaround". The bug can be tested with "make bug".
</p>
<p>
The compiler behaves this way across the versions. I've tested 6.12.3, 7.0.2, 7.0.3, 7.0.4, 7.2.1, 7.2.2.
</p>
<p>
My platform should be irrelevant, but for the sake of completeness:
</p>
<pre class="wiki">Linux raptor 3.1.0-4-ARCH #1 SMP PREEMPT Mon Nov 7 22:47:18 CET 2011 x86_64 Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz GenuineIntel GNU/Linux
</pre><p>
The code for reproducing is attached. Again, run it with "make bug" or simply "make".
</p>
<p>
I'm experimenting with high-performance FIFO queues. The implementation attached is quite potent, capable of processing 40M messages / second on my machine in one-producer one-consumer case.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5645#changelog
http://ghc.haskell.org/trac/ghc/ticket/1853
http://ghc.haskell.org/trac/ghc/ticket/1853#1853: hpc mix files for Main modules overwrite each otherThu, 08 Nov 2007 03:08:12 GMTguest<p>
I have several programs, and hence several files that define Main modules, in the same directory. I build each one with a ghc --make -o Progname. When The hpc mix files describing the compiled modules are dumped in .hpc, the current Main.mix overwrites any previous Main.mix. As a result, I can only get an hpc report from Progname.tix if Progname was the most recent binary to be compiled.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1853#changelog
http://ghc.haskell.org/trac/ghc/ticket/4012
http://ghc.haskell.org/trac/ghc/ticket/4012#4012: Compilation results are not deterministicSat, 24 Apr 2010 13:05:40 GMTkili<p>
There are some issues with non-determinism in the output of GHC, which means that compilations are not repeatable. This affects some users (e.g. Debian packagers) who need to be able to get repeatable hashes for the packages of a GHC build.
</p>
<p>
The cases we know about that lead to non-deterministic results are:
</p>
<ul><li>The <tt>spec_ids</tt> (specialised Ids) attached to an Id have a non-deterministic ordering
</li><li>CSE can give different results depending on the order in which the bindings are considered, and since the ordering is non-deterministic, the result of CSE is also non-deterministic. e.g. in <tt>x = z; y = z; z = 3</tt>, where <tt>y</tt> and <tt>x</tt> are exported, we can end up with either <tt>x = y; y = 3</tt> or <tt>y = x; x = 3</tt>.
</li><li>There seems to be something unpredictable about the order of arguments to <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/SpecConstr">SpecConstr</a>-generated specialisations, see <a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-users/2011-April/020287.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-users/2011-April/020287.html</a>
</li><li>The wrappers generated by the <tt>CApiFFI</tt> extension have non-deterministic names. (see <a class="new" href="http://ghc.haskell.org/trac/ghc/ticket/4012#comment:15" title="Comment 15 for Ticket #4012">comment:15</a> below).
</li></ul><p>
<strong>Old ticket description follows</strong>
</p>
<p>
Short story: if you use ghc-6.12.1.20100318 (or similar, probably
ghc-6.12.1 release will produce the same results) to bootstrap
ghc-6.12, and then use that ghc-6.12 to bootstrap another ghc-6.12,
those two instances of ghc-6.12 will have different ABI hashes and
interfaces in the ghc package. If you use ghc-6.10 for the
bootstrapping, you'll even get differences in the ghc, base and
Cabal packages.
</p>
<p>
Long story: see logfiles and descriptions at <a class="ext-link" href="http://darcs.volkswurst.de/boot-tests/"><span class="icon"></span>http://darcs.volkswurst.de/boot-tests/</a> (note that the logfiles are quite large, I really don't want to attach 150 MB of logs to this ticket).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4012#changelog
http://ghc.haskell.org/trac/ghc/ticket/9600
http://ghc.haskell.org/trac/ghc/ticket/9600#9600: Bad error message: Applicative is not a derivable classTue, 16 Sep 2014 21:10:01 GMTnh2<p>
You have <tt>GeneralizedNewtypeDeriving</tt> on and use <tt>deriving Applicative</tt> with something that you cannot derive Applicative on, GHC correctly says <tt>cannot eta-reduce the representation type enough</tt>.
</p>
<p>
If you don't have <tt>GeneralizedNewtypeDeriving</tt> on yet and deriving Applicative will work, GHC says something like "perhaps you want to enable GeneralizedNewtypeDeriving"?
</p>
<p>
However, if you don't have <tt>GeneralizedNewtypeDeriving</tt> AND if GHC figures out that if you enable it, the next message will be <tt>cannot eta-reduce the representation type enough</tt>, then GHC will state the most unhelpful <tt>Applicative is not a derivable class</tt>, which suggests to me that <strong>in general</strong>, Applicative is not derivable (which is wrong).
</p>
<p>
rwbarton's suggestion: Suggest enabling <tt>GeneralizedNewtypeDeriving</tt> in any case and then let the user see why it cannot be derived.
</p>
<p>
Some relevant #ghc chat:
</p>
<pre class="wiki">rwbarton, that's GND again
rwbarton: I a ~ K a where K = ErrorT ImmError (ReaderT CliOptions (ReaderT Config IO)) is an instance of Applicative
rwbarton: so it can coerce the instance for K to an instance for I
nh2: so is it the error message that is the confusing part here? It suggests that "In general, Applicative is not derivable"
nh2: I mean it as: Shouldn't it give an error message like "can't derive an Applicative instance in this case because ..."?
rwbarton: well maybe it could add something like "Did you mean to use GeneralizedNewtypeDeriving?"
rwbarton: oh I see what you mean, even if you turn that extension on it gives the same error message
nh2: yes, because we already have such a message in some cases
nh2: no, in this case I had really forgotten the extension. If I add it, I get the "cannot eta-reduce the representation type enough" error, but I haven't figured out why I get it in this case yet
rwbarton: I wrote the condition above basically, "I a ~ K a where K = ... is an instance of Applicative" where ~ is the coercion/isomorphism introduced by the newtype
rwbarton: if you can't write down K then you can't use GND because where would it get the instance?
rwbarton: writing down K is eta reduction
nh2: I'm wondering whether it doesn't suggest adding the extension because it already figured out I will not be able to eta-reduce?
rwbarton: oh yeah, it seems so
rwbarton: that seems a bit silly
nh2: in this case, I think we should pimp the error message a bit
nh2: (this is the thing I want to derive bwt: https://github.com/ganeti-github-testing/ganeti-test-1/blob/master/src/Ganeti/BasicTypes.hs#L147)
nh2: what do you think would be the best error message to show in such a case?
nh2: just suggest the GNTD suggestion regardless and let the user see afterwards that it cannot work?
rwbarton: I would just have it always suggest GND ... yeah
nh2: ok I file a ticket for that
rwbarton: seems like more suggestions > fewer suggestions
rwbarton: even if this is a weird second-order case where there are two errors
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/9600#changelog
http://ghc.haskell.org/trac/ghc/ticket/9421
http://ghc.haskell.org/trac/ghc/ticket/9421#9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machineThu, 07 Aug 2014 22:02:16 GMTMikolajKonarski<p>
I'm compiling i386 binaries on amd64 linux and reporting problems and workarounds in this meta ticket.
</p>
<p>
The very first problem I encounter is a magic number mismatch message.
This is basically the same problem as reported here:
</p>
<p>
<a class="ext-link" href="https://www.mail-archive.com/ghc-devs@haskell.org/msg04439.html"><span class="icon"></span>https://www.mail-archive.com/ghc-devs@haskell.org/msg04439.html</a>
</p>
<p>
I have empty .cabal and .ghc, no ghc in paths and I have old Ubuntu LTS (12.04.4) so I was able to install ia32-libs and a few other libs
</p>
<p>
I've downloaded
</p>
<p>
<a href="http://www.haskell.org/ghc/dist/7.8.3/ghc-7.8.3-i386-unknown-linux-deb7.tar.xz">http://www.haskell.org/ghc/dist/7.8.3/ghc-7.8.3-i386-unknown-linux-deb7.tar.xz</a>
</p>
<p>
configured, and make install says:
</p>
<pre class="wiki">Installing library in
/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/haskell98-2.0.0.3
"utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/haskell2010 dist-install "strip" '' '/mikolaj/env/7.8.3i386/local/src/ghc' '/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3' '/mikolaj/env/7.8.3i386/local/src/ghc/share/doc/ghc/html/libraries' 'v p dyn'
Installing library in
/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/haskell2010-1.1.2.0
"/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc-pkg" --force --global-package-db "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/package.conf.d" update rts/dist/package.conf.install
Reading package info from "rts/dist/package.conf.install" ... done.
"utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register libraries/ghc-prim dist-install "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc" "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc-pkg" "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3" '' '/mikolaj/env/7.8.3i386/local/src/ghc' '/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3' '/mikolaj/env/7.8.3i386/local/src/ghc/share/doc/ghc/html/libraries' NO
ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi
magic number mismatch: old/corrupt interface file? (wanted 33214052, got
129742)
make[1]: *** [install_packages] Error 1
make: *** [install] Error 2
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/9421#changelog
http://ghc.haskell.org/trac/ghc/ticket/6079
http://ghc.haskell.org/trac/ghc/ticket/6079#6079: SEH exception handler not implemented on Win64Sat, 05 May 2012 13:07:04 GMTigloo<p>
In <tt>RtsMain.c</tt> we only enable <tt>BEGIN_CATCH</tt>/<tt>END_CATCH</tt> on Win32. I think we need a completely different implementation for Win64.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/6079#changelog
http://ghc.haskell.org/trac/ghc/ticket/2224
http://ghc.haskell.org/trac/ghc/ticket/2224#2224: -fhpc inteferes/prevents rewrite rules from firingThu, 17 Apr 2008 00:54:56 GMTdons<p>
Use case:
</p>
<p>
I'm writing tests for rewrite rules, and using HPC to determine if rules were fired (and their code exercised). HPC is quite cool here, since it lets us see which rules fired, without needing to explicitly export functions to test.
</p>
<p>
However, -fhpc seems to prevent many rules from firing (likely due to ticks getting in the way?)
</p>
<p>
For example:
</p>
<pre class="wiki">import qualified Data.ByteString.Char8 as C
main = print (C.pack "literal")
</pre><p>
When compiled normally, triggers a nice rewrite rule:
</p>
<pre class="wiki">$ ghc -O2 A.hs -ddump-rule-firings A.hs -c
Rule fired: unpack
Rule fired: Class op show
Rule fired: unpack-list
Rule fired: ByteString packChars/packAddress
Rule fired: unpack
Rule fired: Class op show
Rule fired: unpack-list
Rule fired: ByteString packChars/packAddres
</pre><p>
Now with -fhpc:
</p>
<pre class="wiki">$ ghc -O2 A.hs -ddump-rule-firings A.hs -c -fhpc
Rule fired: unpack
Rule fired: Class op show
Rule fired: unpack-list
Rule fired: unpack
Rule fired: Class op show
Rule fired: unpack-list
</pre><p>
What's the best way to ensure the same code is exercised with and without -fhpc here? (I'd quite like to get this working, since rewrite rules benefit from testing.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2224#changelog
http://ghc.haskell.org/trac/ghc/ticket/2991
http://ghc.haskell.org/trac/ghc/ticket/2991#2991: .tix file generation broken with -fhpc and --make flags with lhs modulesFri, 30 Jan 2009 20:21:25 GMTppavel<p>
Assume the project consisting of two files: Main.lhs and MyModule.hs. Main.lhs imports MyModule via standard import. Build the project with
</p>
<p>
ghc --make -fhpc -o main Main.lhs
</p>
<p>
The generated .tix file contains relevant information and hpc markup correctly shows the coverage for MyModule.
</p>
<p>
Now rename MyModule.hs to MyModule.lhs and enclose the code there in \begin{code} / \end{code}. Build again. The compilation still succeeds and the executable works fine. But main.tix now seems wrong and no hpc coverage information is available for MyModule
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2991#changelog
http://ghc.haskell.org/trac/ghc/ticket/8657
http://ghc.haskell.org/trac/ghc/ticket/8657#8657: -fregs-graph still has a limit on spill slotsWed, 08 Jan 2014 10:32:42 GMTsimonmar<p>
The limit on spill slots was removed for the linear register allocator in 7.8, but not for <tt>-fregs-graph</tt>.
</p>
<p>
SHA-1 fails to compile with <tt>-fregs-graph</tt> in 7.8.
</p>
<p>
Related: <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/7679" title="bug: Regression in -fregs-graph performance (new)">#7679</a> (<tt>-fregs-graph</tt> generates poor code with the new codegen).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8657#changelog
http://ghc.haskell.org/trac/ghc/ticket/3782
http://ghc.haskell.org/trac/ghc/ticket/3782#3782: Data Parallel "Impossible happened" compiler errorWed, 23 Dec 2009 21:41:17 GMTguest<p>
When I attempted to compile my vectorized code , I got the following message:
</p>
<pre class="wiki">ghc -c -Odph -fcpr-off -fdph-seq newprop.hs
ghc: panic! (the 'impossible' happened)
(GHC version 6.12.1 for i386-apple-darwin):
sumTyCon 11
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3782#changelog
http://ghc.haskell.org/trac/ghc/ticket/3903
http://ghc.haskell.org/trac/ghc/ticket/3903#3903: DPH bad sliceP causes RTS panic "allocGroup: requested zero blocks"Mon, 01 Mar 2010 08:47:36 GMTbenl<pre class="wiki">$ ghci -XPArr
...
Prelude> :m GHC.PArr
Prelude GHC.PArr> sliceP 10 10 [::]
<interactive>: internal error: allocGroup: requested zero blocks
(GHC version 6.12.1 for i386_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort trap
</pre><p>
<tt>sliceP 10 10 [::]</tt> is bogus. This should have been picked up in the libraries before hitting the RTS assertion.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3903#changelog
http://ghc.haskell.org/trac/ghc/ticket/4081
http://ghc.haskell.org/trac/ghc/ticket/4081#4081: Strict constructor fields inspected in loopWed, 19 May 2010 12:21:26 GMTrl<p>
Here is a small example to illustrate the problem:
</p>
<pre class="wiki">module T where
data S a b = S !a !b
class C a where
make :: a -> S a a
instance C Int where
{-# NOINLINE make #-}
make n = S n n
foo :: (C a, Num a) => a -> Int -> a
{-# INLINE foo #-}
foo x k = k `seq` m `seq` go k 0
where
S m n = make x
go 0 i = i
go k i = go (k-1) (i + m)
</pre><pre class="wiki">module U where
import T
bar :: Int -> Int -> Int
bar s k = foo s k + 1
</pre><p>
Relying on LiberateCase seems to be the only way to unbox <tt>m</tt> outside of the loop in <tt>bar</tt>. The seq in <tt>foo</tt> doesn't help because it gets eliminated immediately.
</p>
<p>
GHC does have enough information to do this:
</p>
<pre class="wiki">U.bar =
\ (s_aaw [Dmd=Just S(A)] :: GHC.Types.Int)
(k_aax [Dmd=Just U(L)] :: GHC.Types.Int) ->
case k_aax
of k1_ajh [Dmd=Just U(L)] { GHC.Types.I# ipv_ajj [Dmd=Just A] ->
case T.$fCInt_$cmake s_aaw of _ { T.S m_ajy [Dmd=Just U(T)] _ ->
...
</pre><p>
Note the demand on <tt>m</tt>. If it was an argument instead of a local binding, it would be unboxed by w/w.
</p>
<p>
Also, the seq does help if we use lazy pairs instead of strict ones.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4081#changelog
http://ghc.haskell.org/trac/ghc/ticket/5807
http://ghc.haskell.org/trac/ghc/ticket/5807#5807: DPH library functions don't work without -fvectorise.Mon, 23 Jan 2012 00:58:29 GMTbenl<p>
Mukesh Tiwari reports:
</p>
<pre class="wiki">ghci>import Data.Array.Parallel
ghci>import Data.Array.Parallel.PArray
ghci>let u = Data.Array.Parallel.PArray.fromList [ 1 .. 10 ]
ghci>:t u
u :: PArray Double
ghci>u
fromList<PArray> [1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0]
ghci>let v = Data.Array.Parallel.fromPArrayP u
ghci>:t v
v :: [:Double:]
ghci>lengthP v
0
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5807#changelog
http://ghc.haskell.org/trac/ghc/ticket/6004
http://ghc.haskell.org/trac/ghc/ticket/6004#6004: dph-lifted-vseg package doesn't provide Data.Array.Parallel.Prelude.Float moduleFri, 13 Apr 2012 18:08:15 GMTshelarcy<p>
dph-lifted-copy package and old dph-par package provide Data.Array.Parallel.Prelude.Float module.
</p>
<ul><li><a class="ext-link" href="http://hackage.haskell.org/package/dph-lifted-copy"><span class="icon"></span>http://hackage.haskell.org/package/dph-lifted-copy</a>
</li><li><a class="ext-link" href="http://hackage.haskell.org/package/dph-par"><span class="icon"></span>http://hackage.haskell.org/package/dph-par</a>
</li></ul><p>
But dph-lifted-vseg package doesn't provide Data.Array.Parallel.Prelude.Float module, now.
</p>
<ul><li><a class="ext-link" href="http://hackage.haskell.org/package/dph-lifted-vseg-0.6.1.2"><span class="icon"></span>http://hackage.haskell.org/package/dph-lifted-vseg-0.6.1.2</a>
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/6004#changelog
http://ghc.haskell.org/trac/ghc/ticket/7063
http://ghc.haskell.org/trac/ghc/ticket/7063#7063: Register allocators can't handle non-uniform register setsMon, 09 Jul 2012 12:51:42 GMTsimonmar<p>
Neither the linear scan register allocator nor the graph-colouring allocator can properly handle the fact that some registers on x86 have 8 and 16-bit versions and some don't. We got away with this until now because the only free registers on x86 were <tt>%eax</tt>, <tt>%ecx</tt> and <tt>%edx</tt>, but now we can also treat <tt>%esi</tt> as free when it isn't being used for R1 (see <a class="changeset" href="http://ghc.haskell.org/trac/ghc/changeset/f857f0741515b9ebf186beb38fe64448de355817/ghc" title="Allow the register allocator access to argument regs (R1.., F1.., etc.)
...">f857f0741515b9ebf186beb38fe64448de355817</a>). However, <tt>%esi</tt> doesn't have an 8-bit version, so we cannot treat it as allocatable because the register allocator will try to use it when an 8-bit register is needed (see <a class="changeset" href="http://ghc.haskell.org/trac/ghc/changeset/105754792adac0802a9a59b0df188b58fb53503f/ghc" title="Don't re-allocate %esi on x86.
Recent changes have freed up %esi for ...">105754792adac0802a9a59b0df188b58fb53503f</a>).
</p>
<p>
LLVM doesn't have this problem, so one workaround is to compile with <tt>-fllvm</tt> to get the extra register(s) on x86.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7063#changelog
http://ghc.haskell.org/trac/ghc/ticket/7098
http://ghc.haskell.org/trac/ghc/ticket/7098#7098: GHC 7.4.1 reports an internal error and core dumps while using DPHThu, 26 Jul 2012 03:40:52 GMTPrasanna<p>
While compiling a DPH program I got the following error,
</p>
<pre class="wiki">Main: internal error: allocGroup: requested zero blocks
(GHC version 7.4.1 for i386_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
</pre><p>
I have attached the code files that I was using.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7098#changelog
http://ghc.haskell.org/trac/ghc/ticket/7316
http://ghc.haskell.org/trac/ghc/ticket/7316#7316: GHC segfaults on ARMTue, 09 Oct 2012 19:33:25 GMTlaney<p>
Sorry for the lack of detail. I thought I'd file this upstream. We've been seeing this in Ubuntu with 7.4.2. Some cabal packages, like chell, fail to build with a segfault in ghc.
</p>
<pre class="wiki">[3 of 4] Compiling Test.Chell.Main ( lib/Test/Chell/Main.hs, dist-ghc/build/Test/Chell/Main.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package old-locale-1.0.0.4 ... linking ... done.
Loading package time-1.4 ... linking ... done.
Loading package random-1.0.1.1 ... linking ... done.
Loading package containers-0.4.2.1 ... linking ... done.
Loading package patience-0.1.1 ... linking ... done.
Loading package bytestring-0.9.2.1 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package monads-tf-0.1.0.0 ... linking ... done.
Loading package text-0.11.2.0 ... linking ... done.
Loading package system-filepath-0.4.6 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package options-0.1.1 ... linking ... done.
make: *** [build-ghc-stamp] Error 11
</pre><p>
Full build log attached. I'll try to reduce the example and/or reproduce with 7.6 soon. (I can also provide you with SSH access to hardware if you need it).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7316#changelog
http://ghc.haskell.org/trac/ghc/ticket/5369
http://ghc.haskell.org/trac/ghc/ticket/5369#5369: Reinstate VECTORISE pragmas with expressions as right-hand sidesTue, 02 Aug 2011 08:23:47 GMTsimonpj<p>
The current vectoriser depends in a very fragile way on the order in which the constraint solver generates constraints. This ticket is just to track this known problem.
</p>
<p>
Manifestation:
</p>
<pre class="wiki">*** Vectorisation error ***
Type mismatch in vectorisation pragma for Data.Array.Parallel.unzipP
Expected type forall a_a1SF b_a1SG.
(Data.Array.Parallel.PArray.PRepr.PA a_a1SF,
Data.Array.Parallel.PArray.PRepr.PA b_a1SG) =>
Data.Array.Parallel.PArray.Base.PArray (a_a1SF, b_a1SG)
Data.Array.Parallel.Lifted.Closure.:-> (Data.Array.Parallel.PArray.Base.PArray
a_a1SF,
Data.Array.Parallel.PArray.Base.PArray
b_a1SG)
Inferred type forall a_a21g b_a21h.
(Data.Array.Parallel.PArray.PRepr.PA b_a21h,
Data.Array.Parallel.PArray.PRepr.PA a_a21g) =>
Data.Array.Parallel.PArray.Base.PArray (a_a21g, b_a21h)
Data.Array.Parallel.Lifted.Closure.:-> (Data.Array.Parallel.PArray.Base.PArray
a_a21g,
Data.Array.Parallel.PArray.Base.PArray
b_a21h)
</pre><p>
Reason: the compilation of VECTORISE pragmas depends on the order of constraints in an inferred type. This isn't trivial to fix. As Manuel writes, the problem here is that we do not know what wrapper w we need *until* the vectoriser runs. Why is that? Given
</p>
<pre class="wiki"> f :: ty
f = e
{-# VECTORISE f = e_v #-}
</pre><p>
where the type *inferred* for <tt>e_v</tt> is <tt>ty_v</tt>, we need to mediate between <tt>ty_v</tt> and <tt>V[[ty]]</tt>. (Here <tt>V[[ty]]</tt> is the transformation that maps a regular type to a vectorised type.)
</p>
<p>
It is <tt>V[[ty]]</tt> that we cannot determine until the vectoriser runs. If we could compute <tt>V[ty]]</tt> in the type checker, we could use it together with <tt>ty_v</tt> to compute a wrapper w as you propose.
</p>
<p>
Alas, given the current implementation of <tt>V[[..]]</tt> in the vectoriser (it is implemented in <tt>Vectorise.Type.vectType</tt>), we cannot call it in the type checker, because it runs in the <tt>VM</tt> monad, which is a variant of the 'DsM' monad. In particular, 'VM' uses some tables of names of types and functions defined in the DPH library that are not available during type checking. (I briefly considered duplicating the code for <tt>vectType</tt> as a stop gap measure in <tt>TcM</tt>, but that didn't seem to be so easy.)
</p>
<p>
I believe that the Right Thing to do is to change the 'VM' monad and the implementation of <tt>vectType</tt>, so that it is more flexible and can be called from <tt>TcM</tt>. The changes that I am making at the moment (i.e., cutting down these tables of magic, built-in things) will make it easier to improve <tt>vectType</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5369#changelog
http://ghc.haskell.org/trac/ghc/ticket/5470
http://ghc.haskell.org/trac/ghc/ticket/5470#5470: The DPH library needs to support PData and PRepr instances for more than 15-tuplesThu, 08 Sep 2011 07:35:15 GMTchak<p>
Currently, <tt>Data.Array.Parallel.PArray.PDataInstances</tt> only generates tuple instances up to 6-tuple. This is not sufficient as these instances are used for environments of closures by the vectoriser — i.e., once a closures has more than 15 free variables, the compiler fails with <tt>VectMonad.lookupFamInst: not found</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5470#changelog
http://ghc.haskell.org/trac/ghc/ticket/5646
http://ghc.haskell.org/trac/ghc/ticket/5646#5646: Initialise tuples using pragmasFri, 18 Nov 2011 02:26:07 GMTchak<p>
Fix <tt>initBuiltinTyCons</tt> in <tt>Vectorise.Builtins.Base</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5646#changelog
http://ghc.haskell.org/trac/ghc/ticket/5702
http://ghc.haskell.org/trac/ghc/ticket/5702#5702: Can't vectorise pattern matching on numeric literalsThu, 15 Dec 2011 06:43:49 GMTchak<p>
Trying to vectorise
</p>
<pre class="wiki">toBool :: Int -> Bool
toBool 0 = False
toBool _ = True
</pre><p>
we get
</p>
<pre class="wiki">*** Vectorisation error ***
Can't vectorise expression GHC.Prim.Int#
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5702#changelog
http://ghc.haskell.org/trac/ghc/ticket/7078
http://ghc.haskell.org/trac/ghc/ticket/7078#7078: Panic using mixing list with parallel arrays incorrectlyMon, 16 Jul 2012 07:48:55 GMTNeilJ<pre class="wiki">ghc: panic! (the 'impossible' happened)
(GHC version 7.4.1 for i386-unknown-linux):
DsMonad: uninitialised ds_parr_bi
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/7078#changelog
http://ghc.haskell.org/trac/ghc/ticket/5615
http://ghc.haskell.org/trac/ghc/ticket/5615#5615: ghc produces poor code for `div` with constant powers of 2.Wed, 09 Nov 2011 09:38:08 GMTLennart<p>
The code for Int <tt>(div x c)</tt> where <tt>c</tt> is a constant of the form 2<sup>n</sup> should be implemented with an arithmetic right shift, currently it's a call to a function. This optimization should be done for all signed types.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5615#changelog
http://ghc.haskell.org/trac/ghc/ticket/10065
http://ghc.haskell.org/trac/ghc/ticket/10065#10065: Definition of fix lacks commentaryWed, 04 Feb 2015 17:14:03 GMTdfeuer<p>
In <tt>Data.Function</tt>,
</p>
<div class="code"><pre><span class="nf">fix</span> <span class="ow">::</span> <span class="p">(</span>a <span class="ow">-></span> a<span class="p">)</span> <span class="ow">-></span> a
<span class="nf">fix</span> f <span class="ow">=</span> <span class="kr">let</span> x <span class="ow">=</span> f x <span class="kr">in</span> x
</pre></div><p>
It is not immediately obvious why it is defined like this, rather than the more natural
</p>
<div class="code"><pre><span class="nf">fix</span> f <span class="ow">=</span> f <span class="p">(</span>fix f<span class="p">)</span>
</pre></div><p>
There are very good reasons for this; notably, it allows for the definition of circular data structures. But there should be a comment explaining this, preferably in the Haddocks.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/10065#changelog
http://ghc.haskell.org/trac/ghc/ticket/8178
http://ghc.haskell.org/trac/ghc/ticket/8178#8178: Need TypeRep for Symbol and numeric type literals; and Typeable instancesTue, 27 Aug 2013 11:45:28 GMTsimonpj<p>
Nicolas Trangez points out that we don't have a <tt>TypeRep</tt> for types involving literal strings or numerics. E.g. what is <tt>(typeRep (undefined :: Proxy "foo"))</tt>?
</p>
<p>
Here is Nicolas's example:
</p>
<pre class="wiki">{-# LANGUAGE DataKinds,
KindSignatures,
DeriveFunctor,
DeriveDataTypeable #-}
module Main where
import Data.Typeable
import GHC.TypeLits
data NoSymbol n a b = NoSymbol a b
deriving (Typeable)
data WithSymbol (n :: Symbol) a b = WithSymbol a b
deriving (Typeable)
data Sym
deriving (Typeable)
main :: IO ()
main = do
print $ typeOf (undefined :: NoSymbol Sym Int Int)
let d = undefined :: WithSymbol "sym" Int Int
{-
print $ typeOf d
No instance for (Typeable Symbol "sym")
arising from a use of ‛typeOf’
-}
return ()
</pre><p>
Just as types contain literal strings and natural numbers, so too must <tt>TypeRep</tt>, in some way. Once we have a suitable <tt>TypeRep</tt> we can make built-in instance for <tt>Typeable</tt> that return the appropriate representation.
</p>
<p>
At the moment we have (in <tt>Data.Typeable.Internals</tt>):
</p>
<pre class="wiki">data TypeRep = TypeRep {-# UNPACK #-} !Fingerprint TyCon [TypeRep]
data TyCon = TyCon {
tyConHash :: {-# UNPACK #-} !Fingerprint,
tyConPackage :: String,
tyConModule :: String,
tyConName :: String
}
</pre><p>
with instances for Eq and Ord. Perhaps we need
</p>
<pre class="wiki">data TypeRep
= TcApp {-# UNPACK #-} !Fingerprint TyCon [TypeRep]
| TcSym String
| TcNat Integer
</pre><p>
or something like that? I'm not certain. I think Iavor is going to think about it.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8178#changelog
http://ghc.haskell.org/trac/ghc/ticket/9260
http://ghc.haskell.org/trac/ghc/ticket/9260#9260: Unnecessary error using GHC.TypeLitsThu, 03 Jul 2014 08:08:47 GMTIceland_jack<p>
Compiling:
</p>
<pre class="wiki">{-# LANGUAGE DataKinds, TypeOperators, GADTs #-}
module Error where
import GHC.TypeLits
data Fin n where
Fzero :: Fin (n + 1)
Fsucc :: Fin n -> Fin (n + 1)
test :: Fin 1
test = Fsucc Fzero
</pre><p>
gives a strange (unnecessary) error message claiming that <tt>Fin 1</tt> doesn't match the expected type <tt>Fin (0 + 1)</tt>:
</p>
<pre class="wiki">% ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.2
% ghc -ignore-dot-ghci /tmp/Error.hs
[1 of 1] Compiling Error ( /tmp/Error.hs, /tmp/Error.o )
/tmp/Error.hs:12:8:
Couldn't match type ‘0’ with ‘1’
Expected type: Fin 1
Actual type: Fin (0 + 1)
In the expression: Fsucc Fzero
In an equation for ‘test’: test = Fsucc Fzero
/tmp/Error.hs:12:14:
Couldn't match type ‘1’ with ‘0’
Expected type: Fin 0
Actual type: Fin (0 + 1)
In the first argument of ‘Fsucc’, namely ‘Fzero’
In the expression: Fsucc Fzero
%
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/9260#changelog
http://ghc.haskell.org/trac/ghc/ticket/9708
http://ghc.haskell.org/trac/ghc/ticket/9708#9708: Type inference non-determinism due to improvementTue, 21 Oct 2014 13:43:54 GMTsimonpj<p>
Here's an example that showed up in Iavor's test <tt>TcTypeNatSimple</tt>:
</p>
<pre class="wiki"> ti7 :: (x <= y, y <= x) => Proxy (SomeFun x) -> Proxy y -> ()
ti7 _ _ = ()
</pre><p>
From the ambiguity check for <tt>ti7</tt> we get this constraint
</p>
<pre class="wiki"> forall x y. (x <= y, y <= x)
=> ( SomeFun x ~ SomeFun alpha
, alpha <= y, y <= alpha)
</pre><p>
where <tt>alpha</tt> is the unification variable that instantiates <tt>x</tt>.
</p>
<p>
Now, from the givens, improvement gives a derived <tt>[D] x~y</tt>, but we can't actually use that to rewrite anything; we have no evidence.
</p>
<p>
From the wanteds we can use improvement in two alternative ways:
</p>
<pre class="wiki">1. (alpha <= y, y <= alpha) => [D] alpha ~ y
2. (x <= y, y <= alpha) => [D] x <= alpha
(alpha <= y, y <= x) => [D] alpha <= x
And combining the latter two we get [D] (alpha ~ x)
</pre><p>
It is (2) that we want. But if we get (1) and fix <tt>alpha := y</tt>, we get an error <tt>Can't unify (SomeFun x ~ SomeFun y)</tt>.
</p>
<p>
I think it's a fluke that this test has been working so far; in my new flatten-skolem work it has started failing, which is not unreasonable. What I HATE is that whether type checking succeeds or fails depends on some random choice about which constraint is processed first.
</p>
<p>
The real bug is that the derived Given has no evidence, and can't be used for rewriting. I think Iavor is fixing this deficiency for. I speculate that the same problem might also show up with ordinary type-class functional dependencies, but I have not found a concrete example.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9708#changelog
http://ghc.haskell.org/trac/ghc/ticket/5642
http://ghc.haskell.org/trac/ghc/ticket/5642#5642: Deriving Generic of a big type takes a long time and lots of spaceThu, 17 Nov 2011 01:59:06 GMTbasvandijk<p>
If I load the following module into <tt>ghci</tt> my system will run out of memory after about 15 minutes:
</p>
<pre class="wiki">{-# LANGUAGE DeriveGeneric #-}
import GHC.Generics
data BigSum =
C0 | C1 | C2 | C3 | C4 | C5 | C6 | C7 | C8 | C9
| C10 | C11 | C12 | C13 | C14 | C15 | C16 | C17 | C18 | C19
| C20 | C21 | C22 | C23 | C24 | C25 | C26 | C27 | C28 | C29
| C30 | C31 | C32 | C33 | C34 | C35 | C36 | C37 | C38 | C39
| C40 | C41 | C42 | C43 | C44 | C45 | C46 | C47 | C48 | C49
| C50 | C51 | C52 | C53 | C54 | C55 | C56 | C57 | C58 | C59
| C60 | C61 | C62 | C63 | C64 | C65 | C66 | C67 | C68 | C69
| C70 | C71 | C72 | C73 | C74 | C75 | C76 | C77 | C78 | C79
| C80 | C81 | C82 | C83 | C84 | C85 | C86 | C87 | C88 | C89
| C90 | C91 | C92 | C93 | C94 | C95 | C96 | C97 | C98 | C99
| C100 | C101 | C102 | C103 | C104 | C105 | C106 | C107 | C108 | C109
| C110 | C111 | C112 | C113 | C114 | C115 | C116 | C117 | C118 | C119
| C120 | C121 | C122 | C123 | C124 | C125 | C126 | C127 | C128 | C129
| C130 | C131 | C132 | C133 | C134 | C135 | C136 | C137 | C138 | C139
| C140 | C141 | C142 | C143 | C144 | C145 | C146 | C147 | C148 | C149
| C150 | C151 | C152 | C153 | C154 | C155 | C156 | C157 | C158 | C159
| C160 | C161 | C162 | C163 | C164 | C165 | C166 | C167 | C168 | C169
| C170 | C171 | C172 | C173 | C174 | C175 | C176 | C177 | C178 | C179
| C180 | C181 | C182 | C183 | C184 | C185 | C186 | C187 | C188 | C189
| C190 | C191 | C192 | C193 | C194 | C195 | C196 | C197 | C198 | C199
| C200 | C201 | C202 | C203 | C204 | C205 | C206 | C207 | C208 | C209
| C210 | C211 | C212 | C213 | C214 | C215 | C216 | C217 | C218 | C219
| C220 | C221 | C222 | C223 | C224 | C225 | C226 | C227 | C228 | C229
| C230 | C231 | C232 | C233 | C234 | C235 | C236 | C237 | C238 | C239
| C240 | C241 | C242 | C243 | C244 | C245 | C246 | C247 | C248 | C249
| C250 | C251 | C252 | C253 | C254 | C255 | C256 | C257 | C258 | C259
| C260 | C261 | C262 | C263 | C264 | C265 | C266 | C267 | C268 | C269
| C270 | C271 | C272 | C273 | C274 | C275 | C276 | C277 | C278 | C279
| C280 | C281 | C282 | C283 | C284 | C285 | C286 | C287 | C288 | C289
| C290 | C291 | C292 | C293 | C294 | C295 | C296 | C297 | C298 | C299
deriving Generic
</pre><p>
Big products have the same problem:
</p>
<pre class="wiki">data BigProduct = C
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
() () () () () () () () () ()
deriving Generic
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5642#changelog
http://ghc.haskell.org/trac/ghc/ticket/9453
http://ghc.haskell.org/trac/ghc/ticket/9453#9453: The example for GHC Generics is kinda brokenSun, 17 Aug 2014 19:56:08 GMTFeuerbach<p>
From <a class="ext-link" href="http://www.reddit.com/r/haskell/comments/2douzn/problem_with_popular_ghcgenerics_example/"><span class="icon"></span>http://www.reddit.com/r/haskell/comments/2douzn/problem_with_popular_ghcgenerics_example/</a>:
</p>
<blockquote>
<p>
The popular GHC.Generics serialization example at <a href="http://www.haskell.org/ghc/docs/latest/html/users_guide/generic-programming.html#idp25226064">http://www.haskell.org/ghc/docs/latest/html/users_guide/generic-programming.html#idp25226064</a> illustrates how to serialize a sum datatype (a :+: b), with a 0 bit representing a and a 1 bit representing b.
However, consider a :+: b :+: c.
If the compiler treats this as (a :+: b) :+: c, then a is 00, b is 01, c is 1.
If it's a :+: (b :+: c), then a is 0, b is 10, c is 11.
The compiler's decision, even though (as I understand it) consistent for any given compile, could differ later.
The manual, at <a class="ext-link" href="http://hackage.haskell.org/package/generic-deriving-1.6.3/docs/Generics-Deriving-Base.html#g:9"><span class="icon"></span>http://hackage.haskell.org/package/generic-deriving-1.6.3/docs/Generics-Deriving-Base.html#g:9</a> states not to depend on the ordering, which the example does.
</p>
</blockquote>
<p>
I think this is a valid concern, and the manual should be at least updated to discuss this problem.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9453#changelog
http://ghc.haskell.org/trac/ghc/ticket/9821
http://ghc.haskell.org/trac/ghc/ticket/9821#9821: DeriveAnyClass support for higher-kinded classes + some more commentsFri, 21 Nov 2014 09:51:14 GMTdreixel<p>
<a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/5462" title="feature request: Deriving clause for arbitrary classes (closed: fixed)">#5462</a> was merged before a few final fixes were done. This ticket serves to record that. Left to address are:
</p>
<p>
<a class="ext-link" href="https://phabricator.haskell.org/D476?id=1443#inline-3652"><span class="icon"></span>https://phabricator.haskell.org/D476?id=1443#inline-3652</a>
</p>
<p>
<a class="ext-link" href="https://phabricator.haskell.org/D476?id=1443#inline-3648"><span class="icon"></span>https://phabricator.haskell.org/D476?id=1443#inline-3648</a>
</p>
<p>
<a class="ext-link" href="https://phabricator.haskell.org/D476?id=1443#inline-3646"><span class="icon"></span>https://phabricator.haskell.org/D476?id=1443#inline-3646</a>
</p>
<p>
Also, <tt>DeriveAnyClass</tt> currently panics at higher-kinded classes (like <tt>((* -> *) -> *) -> Constraint</tt>).
</p>
<p>
I'll fix this.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9821#changelog
http://ghc.haskell.org/trac/ghc/ticket/9858
http://ghc.haskell.org/trac/ghc/ticket/9858#9858: Typeable instances should be kind-awareWed, 03 Dec 2014 16:27:56 GMTdreixel<pre class="wiki">{-# LANGUAGE DataKinds #-}
{-# LANGUAGE AutoDeriveTypeable #-}
import Data.Typeable
data A = A
main = print $ typeRep (Proxy :: Proxy A) == typeRep (Proxy :: Proxy 'A)
</pre><p>
This returns <tt>True</tt>, but it should return <tt>False</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9858#changelog
http://ghc.haskell.org/trac/ghc/ticket/9968
http://ghc.haskell.org/trac/ghc/ticket/9968#9968: DeriveAnyClass fails on multi-parameter type classesThu, 08 Jan 2015 19:39:46 GMTgoldfire<p>
When I say
</p>
<pre class="wiki">{-# LANGUAGE DeriveAnyClass, MultiParamTypeClasses #-}
module Bug where
class C a b
data X
deriving (C Int)
</pre><p>
and load that into GHCi, I see this:
</p>
<pre class="wiki">*Main> :load "/Users/rae/temp/DeriveAny.hs"
[1 of 1] Compiling Bug ( /Users/rae/temp/DeriveAny.hs, interpreted )
Var/Type length mismatch:
[b_a2YW]
[]
Var/Type length mismatch:
[b_a2YW]
[]
Ok, modules loaded: Bug.
*Bug> :info C
class C a b -- Defined at /Users/rae/temp/DeriveAny.hs:5:1
instance C X -- Defined at /Users/rae/temp/DeriveAny.hs:7:13
</pre><p>
It seems my <tt>Int</tt> parameter to <tt>C</tt> is being dropped. I don't believe I have a debug build in this example, so that debugging output is shipping.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9968#changelog
http://ghc.haskell.org/trac/ghc/ticket/5786
http://ghc.haskell.org/trac/ghc/ticket/5786#5786: Dynanmic way fails when GHC built with LLVM backendTue, 17 Jan 2012 02:30:06 GMTdterei<p>
If I build GHC with the LLVM backend then the 'Dyn' testsuite way fails completely (tested on x64).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5786#changelog
http://ghc.haskell.org/trac/ghc/ticket/7297
http://ghc.haskell.org/trac/ghc/ticket/7297#7297: LLVM incorrectly hoisting loadsThu, 04 Oct 2012 18:29:14 GMTdterei<p>
test 367_letnoescape fails under LLVM as a load of the HpLim register is hoisted out of the loop. So yielding is never done.
</p>
<p>
What I am not sure about right now is the best way to fix. Loads in LLVM can be annotated in a few different ways to fix this and not sure which one is the most 'correct'.
</p>
<p>
All the following work:
</p>
<ul><li>mark the load as volatile. (seems to give nicest code as well)
</li><li>mark the load as atomic with either monotonic or seq_cst ordering.
</li><li>mark the load as both volatile and atomic.
</li></ul><p>
This bug while only affecting a single test case seems very serious and potentially indicative of a large problem. How well are we communicating the load/store threaded semantics to LLVM?
</p>
<p>
And what semantics do we need to communicate? I think we are fine other than the STG registers...
</p>
<p>
So making a bug for now as I don't know yet the best way to proceed without dedicating some time to reading LLVM docs and probably talking to the LLVM devs as the docs on the memory model are fairly confusing.
</p>
<p>
e.g., Code in question:
</p>
<p>
Bad version (LBB0_1 loops forever as load hoisted out):
</p>
<pre class="wiki">r1Uf_info: # @r1Uf_info
# BB#0: # %c1Vy
movq 144(%r13), %rax
decq %r14
.align 16, 0x90
.LBB0_1: # %tailrecurse
# =>This Inner Loop Header: Depth=1
incq %r14
testq %rax, %rax
jne .LBB0_1
# BB#2: # %c1VD
movq -8(%r13), %rax
movl $r1Uf_closure, %ebx
jmpq *%rax # TAILCALL
</pre><p>
Code when marked with atomic (either monatonic or seq_cst) or both atomic and volatile:
</p>
<pre class="wiki">r1Uf_info: # @r1Uf_info
# BB#0: # %c1Vy
decq %r14
.align 16, 0x90
.LBB0_1: # %tailrecurse
# =>This Inner Loop Header: Depth=1
incq %r14
movq 144(%r13), %rax
testq %rax, %rax
jne .LBB0_1
# BB#2: # %c1VD
movq -8(%r13), %rax
movl $r1Uf_closure, %ebx
jmpq *%rax # TAILCALL
</pre><p>
Code when marked volatile:
</p>
<pre class="wiki">r1Uf_info: # @r1Uf_info
# BB#0: # %c1Vy
decq %r14
.align 16, 0x90
.LBB0_1: # %tailrecurse
# =>This Inner Loop Header: Depth=1
incq %r14
cmpq $0, 144(%r13)
jne .LBB0_1
# BB#2: # %c1VD
movq -8(%r13), %rax
movl $r1Uf_closure, %ebx
jmpq *%rax # TAILCALL
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/7297#changelog
http://ghc.haskell.org/trac/ghc/ticket/7666
http://ghc.haskell.org/trac/ghc/ticket/7666#7666: excessive space and time usage for rendering (somewhat) deeply nested DocsWed, 06 Feb 2013 10:35:46 GMTj.waldmann<p>
I was running into serious performance problems when printing moderately sized Doc and Xml data (HaXml goes via Doc).
</p>
<p>
Since pretty is shipped with ghc, this is potentially dangerous. Users will just assume that these core components are tried and tested, and working efficiently.
</p>
<p>
More info:
<a class="ext-link" href="http://article.gmane.org/gmane.comp.lang.haskell.cafe/103210"><span class="icon"></span>http://article.gmane.org/gmane.comp.lang.haskell.cafe/103210</a>
</p>
<p>
See also:
<a class="ext-link" href="http://stackoverflow.com/questions/9761507/which-pretty-print-library"><span class="icon"></span>http://stackoverflow.com/questions/9761507/which-pretty-print-library</a>
</p>
<p>
Test case (builds an Xml tree with HaXml and renders it via the pretty library):
<a class="ext-link" href="https://github.com/jwaldmann/haskell-tpdb/blob/master/test/speed.hs"><span class="icon"></span>https://github.com/jwaldmann/haskell-tpdb/blob/master/test/speed.hs</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7666#changelog
http://ghc.haskell.org/trac/ghc/ticket/8244
http://ghc.haskell.org/trac/ghc/ticket/8244#8244: Removing the Cabal dependencyFri, 06 Sep 2013 15:17:10 GMTnh2<p>
GHC depends on cabal, which is so far has been problematic many times, for many reasons.
</p>
<p>
A few discussions include:
</p>
<ul><li><a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2013-September/108746.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2013-September/108746.html</a>
</li><li><a class="ext-link" href="http://www.haskell.org/pipermail/ghc-devs/2013-March/000821.html"><span class="icon"></span>http://www.haskell.org/pipermail/ghc-devs/2013-March/000821.html</a>
</li></ul><p>
GHC uses only a very small part of Cabal, in these files:
</p>
<pre class="wiki">./compiler/ghci/Linker.lhs
./compiler/main/Packages.lhs
./compiler/main/PackageConfig.hs
./compiler/main/Finder.lhs
</pre><p>
plus 1 file for ghc-pkg: ./utils/ghc-pkg/Main.hs (see <a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2013-September/108750.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2013-September/108750.html</a> for details).
</p>
<p>
It was proposed that either
</p>
<ul><li>the package format could be a plain specification without direct code dependencies
</li><li>the Cabal package could be split off into Cabal-the-build-system and a minimal part to describe the package DB to be shared by Cabal and GHC
</li></ul><p>
The Cabal part that is used is in only a few modules of Distribution.* while the remaining majority of the Cabal-the-library package is not used (e.g. none of Distribution.Simple.*).
</p>
<p>
Decoupling GHC and Cabal seems to be a public desire, yet there are some problems with these approaches. Let us discuss them in this ticket.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8244#changelog
http://ghc.haskell.org/trac/ghc/ticket/427
http://ghc.haskell.org/trac/ghc/ticket/427#427: Random.StdGen slownessWed, 27 Jul 2005 08:32:05 GMTremit<pre class="wiki">Two (performance) problems in one:
{-# OPTIONS -fffi #-}
module Main (main) where
import Control.Monad
import Random
foreign import ccall unsafe "random" _crandom :: IO Int
randomInt :: (Int, Int) -> IO Int
randomInt (min,max) = do
n <- _crandom
return $ min + n `rem` range
where
range = max - min + 1
main = replicateM_ (5*10^6) $ do
x <- randomRIO (0::Int,1000) :: IO Int
x `seq` return ()
return ()
First, without the "seq" at the end, hardly anything is
evaluated and we're building huge amounts of thunks.
Three ideas about this one:
- Blame the user :)
- data StdGen = StdGen !Int !Int
Use strict fields in StdGen. Doesn't actually help
(at least in this example).
- Force evaluation of the StdGen in getStdRandom.
Does help in this example, but also changes behaviour
of the library:
x <- randomRIO undefined
currently dies only when x (or the result of a later
randomRIO) is evaluated. This change causes it to die
immediately.
Second, even _with_ the "seq", replacing "randomRIO" by
"randomInt" speeds the thing up with a factor of about
30. (2 to 3.6, in a "real world" university practicum
exercise of 900 lines of code)
Even given the fact that they're not really doing the
same thing, this seems rather much :(
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/427#changelog
http://ghc.haskell.org/trac/ghc/ticket/1062
http://ghc.haskell.org/trac/ghc/ticket/1062#1062: Bad output from Text.PrettyPrint.HughesPJTue, 19 Dec 2006 23:13:53 GMTigloo<p>
This program:
</p>
<pre class="wiki">import Text.PrettyPrint.HughesPJ
ncat x y = nest 4 $ cat [ x, y ]
d1 = foldl1 ncat $ take 50 $ repeat $ char 'a'
d2 = parens $ sep [ d1, text "+" , d1 ]
main = print d2
</pre><p>
generates the output below. I haven't worked out what is expected, but this certainly doesn't look right to me (in particular, the space before the <tt>a</tt> on the third line of the output).
</p>
<pre class="wiki">% runghc pp1.hs | tr ' ' _
(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+___________________________________________________________________________________________________________________________________________________________________________________________________a
_a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a)
</pre><p>
The pp1 test goes on to say:
</p>
<pre class="wiki">This code used to print an infinite string, by calling 'spaces'
with a negative argument. There's a patch in the library now,
which makes 'spaces' do somehthing sensible when called with a negative
argument, but it really should not happen at all.
This output is not what is expected, becuase the
test "works" now, by virtue of a hack in HughesPJ.spaces.
I'm leaving this strange output here to remind us to look
at the root cause of the problem. Sometime.
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1062#changelog
http://ghc.haskell.org/trac/ghc/ticket/1487
http://ghc.haskell.org/trac/ghc/ticket/1487#1487: unix package: test needed for getLoginNameTue, 03 Jul 2007 10:51:27 GMTsimonmar<p>
I disabled the test for <tt>getLoginName</tt> in unix/tests/user001 because <tt>getLoginName</tt> cannot be called unless stdin is a terminal, which it isn't during an unattended build. Perhaps we can test this by setting up a pseudoterminal first, but that requires the pty patches which aren't in yet.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1487#changelog
http://ghc.haskell.org/trac/ghc/ticket/2140
http://ghc.haskell.org/trac/ghc/ticket/2140#2140: cpuTimePrecision is wrong for me on Windows (XP)Thu, 06 Mar 2008 11:59:02 GMTguest<p>
(From Adrian Hey)
</p>
<p>
Looking at the source code, this seems to be fixed
at 1000000000 independent of hardware. I'm not sure
if this is supposed to be the same on all Windows XP systems, but it's wrong on my machine at least.
</p>
<p>
getCPUTime always returns a multiple of 15625000000
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2140#changelog
http://ghc.haskell.org/trac/ghc/ticket/2280
http://ghc.haskell.org/trac/ghc/ticket/2280#2280: randomR too slowTue, 13 May 2008 13:00:42 GMTguest<p>
randomR is considerably slower than implementing it manually. Maybe I have not re-implemented it precisely, maybe it is just not inlined.
</p>
<pre class="wiki">module Main (main) where
import System.Random (RandomGen(..), randomR, )
import qualified Data.ByteString as B
newtype KnuthRandomGen = KnuthRandomGen Int
{-# INLINE knuthFactor #-}
knuthFactor :: Int
knuthFactor = 40692
{-# INLINE knuthModulus #-}
knuthModulus :: Int
knuthModulus = 2^(31::Int)-249
-- we have to split the 32 bit integer in order to avoid overflow on multiplication
knuthSplit :: Int
knuthSplit = succ $ div knuthModulus knuthFactor
knuthSplitRem :: Int
knuthSplitRem = knuthSplit * knuthFactor - knuthModulus
instance RandomGen KnuthRandomGen where
{-# INLINE next #-}
next (KnuthRandomGen s) =
-- efficient computation of @mod (s*knuthFactor) knuthModulus@ without Integer
let (sHigh, sLow) = divMod s knuthSplit
in (s, KnuthRandomGen $ flip mod knuthModulus $
knuthSplitRem*sHigh + knuthFactor*sLow)
{-# INLINE split #-}
split (KnuthRandomGen s) =
(KnuthRandomGen (s*s), KnuthRandomGen (13+s))
{-# INLINE genRange #-}
genRange _ = (1, pred knuthModulus)
main :: IO ()
main =
do
-- for comparison: that's very fast
putStrLn "constant"
B.writeFile "random.out" $ fst $
B.unfoldrN 10000000
(\g0@(KnuthRandomGen s) -> Just (fromIntegral s, g0))
(KnuthRandomGen 1)
-- 3 seconds on my machine
putStrLn "immediate"
B.writeFile "random.out" $ fst $
B.unfoldrN 10000000
(\g0 -> let (w,g1) = next g0
in Just (fromIntegral (mod w 256), g1))
(KnuthRandomGen 1)
-- 10 seconds on my machine
putStrLn "randomR"
B.writeFile "random.out" $ fst $
B.unfoldrN 10000000
(\g0 -> Just (let (w,g1) = randomR (0,255) g0
in (fromIntegral (w::Int), g1)))
(KnuthRandomGen 1)
{-
ghc -o dist/build/randomtest -O -Wall -package bytestring-0.9.0.5 -ddump-simpl-iterations speedtest/RandomTest.hs
-}
{-
bytestring-0.9.0.1 as shipped with GHC-6.8.2 does not inline Data.ByteString.unfoldrN
-}
</pre><p>
Is this related to Ticket 427?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2280#changelog
http://ghc.haskell.org/trac/ghc/ticket/3575
http://ghc.haskell.org/trac/ghc/ticket/3575#3575: mkStdGen and split conspire to make some programs predictableMon, 12 Oct 2009 04:45:04 GMTrwbarton<p>
The following program <tt>random.hs</tt> is intended to produce a line containing 30 random 0s or 1s. It is not an example of the best way to use System.Random, but it looks innocuous enough.
</p>
<pre class="wiki">import Control.Monad
import System.Random
print0or1 = do
g <- newStdGen
putStr . show . fst $ randomR (0, 1 :: Int) g
main = replicateM_ 30 print0or1 >> putStrLn ""
</pre><p>
Let's try running it a thousand times:
</p>
<pre class="wiki">rwbarton@functor:/tmp$ ghc-6.10.1 -O2 --make random
[1 of 1] Compiling Main ( random.hs, random.o )
Linking random ...
rwbarton@functor:/tmp$ for i in `seq 1 1000` ; do ./random >> random.out ; done
rwbarton@functor:/tmp$ sort random.out | uniq | wc -l
60
</pre><p>
That's odd... there are 2<sup>30</sup> possible output lines, but when I tried to generate 1000 random ones, I only got 60 distinct outputs. Why did that happen?
</p>
<p>
One might think this is due to poor initial seeding of the random number generator (due to the time not changing very much during the test), but this is not the case. Attached is a fancier version of the program which reads an initial seed from <tt>/dev/urandom</tt>; it exhibits the same behavior.
</p>
<p>
This phenomenon is not too hard to explain. It is ultimately due to a poor interaction between <tt>mkStdGen</tt> and <tt>split</tt>. First, we need to know a bit about the design of System.Random (some statements simplified slightly for this discussion).
</p>
<ul><li>The state of the RNG consists of two <tt>Int32</tt>s, <tt>s1</tt> and <tt>s2</tt>.
</li></ul><ul><li>The initial state produced by mkStdGen almost always has <tt>s2</tt> equal to 1. (Extremely rarely, it might have <tt>s2</tt> equal to 2. We'll ignore this as it doesn't affect the argument.)
</li></ul><ul><li>To generate a random 0 or 1, we first generate a new state using some simple functions <tt>s1' = next1(s1)</tt>, <tt>s2' = next2(s2)</tt>. (Note that <tt>s1</tt> and <tt>s2</tt> "evolve" independently.) The random value returned is the lowest bit of <tt>s1'</tt> minus <tt>s2'</tt>.
</li></ul><ul><li>Splitting the generator <tt>(s1, s2)</tt> yields the two generators <tt>(s1+1, next2(s2))</tt> and <tt>(next1(s1), s2-1)</tt>.
</li></ul><p>
Our program functions as follows.
</p>
<ul><li>Initialize the generator stored in <tt>theStdGen</tt> (<tt>s1</tt> is some varying value <tt>a</tt>, <tt>s2</tt> is 1).
</li></ul><ul><li>Repeatedly split the generator, replacing it with the first output, and use the second output to generate a 0 or 1.
</li></ul><p>
If we watch <tt>theStdGen</tt> while our program runs, we will see that <tt>s1</tt> is incremented by 1 at each step, while <tt>s2</tt> follows the fixed sequence <tt>1</tt>, <tt>next2(1)</tt>, <tt>next2(next2(1))</tt>, etc. The 0 or 1 we output at the <tt>k</tt>th step is thus the lowest bit of <tt>next1(next1(a+k-1))</tt> minus <tt>b</tt><sub>k</sub>, where <tt>b</tt><sub>k</sub> is some fixed sequence. And as <tt>k</tt> varies, <tt>next1(next1(a+k-1))</tt> turns out to be just an arithmetic sequence with fixed difference modulo a fixed prime so its lowest bits are extremely predictable even without knowing <tt>a</tt>.
</p>
<p>
This issue can be fixed to some extent, without breaking backwards compatibility, by adding another method (besides <tt>mkStdGen</tt>) to create a generator, which does not have predictable <tt>s2</tt>, and using it to initialize the system RNG.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3575#changelog
http://ghc.haskell.org/trac/ghc/ticket/3606
http://ghc.haskell.org/trac/ghc/ticket/3606#3606: The Ord instance for unboxed arrays is very inefficientThu, 22 Oct 2009 20:48:50 GMTblarsen<p>
The Ord instance for unboxed arrays defined in <tt>Data.Array.Base</tt> results in code that makes lots of heap allocations and is very slow.
</p>
<p>
For the record, the <tt>Ord</tt> instance is defined as so in <tt>Data.Array.Base</tt>:
</p>
<div class="code"><pre><span class="kr">instance</span> <span class="p">(</span><span class="kt">Ix</span> ix<span class="p">,</span> <span class="kt">Ord</span> e<span class="p">,</span> <span class="kt">IArray</span> <span class="kt">UArray</span> e<span class="p">)</span> <span class="ow">=></span> <span class="kt">Ord</span> <span class="p">(</span><span class="kt">UArray</span> ix e<span class="p">)</span> <span class="kr">where</span>
compare <span class="ow">=</span> cmpUArray
<span class="cm">{-# INLINE cmpUArray #-}</span>
<span class="nf">cmpUArray</span> <span class="ow">::</span> <span class="p">(</span><span class="kt">IArray</span> <span class="kt">UArray</span> e<span class="p">,</span> <span class="kt">Ix</span> i<span class="p">,</span> <span class="kt">Ord</span> e<span class="p">)</span> <span class="ow">=></span> <span class="kt">UArray</span> i e <span class="ow">-></span> <span class="kt">UArray</span> i e <span class="ow">-></span> <span class="kt">Ordering</span>
<span class="nf">cmpUArray</span> arr1 arr2 <span class="ow">=</span> compare <span class="p">(</span>assocs arr1<span class="p">)</span> <span class="p">(</span>assocs arr2<span class="p">)</span>
</pre></div><p>
The <tt>assocs</tt> calls don't appear to be deforested away, and hence, when using the <tt>Ord</tt> functions on unboxed arrays, the performance is bad to the point of making them unusable.
</p>
<p>
It seems reasonable to me that <tt>compare</tt> for unboxed arrays could be implemented strictly, in a tight loop, without any heap allocations at all.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3606#changelog
http://ghc.haskell.org/trac/ghc/ticket/3620
http://ghc.haskell.org/trac/ghc/ticket/3620#3620: The seeds generated by split are not independentWed, 28 Oct 2009 15:07:41 GMTNickSmallbone<p>
Suppose we split a seed into two like this:
</p>
<pre class="wiki">split' :: StdGen -> (StdGen, StdGen)
split' g = (g12, g21)
where (_, g12) = split g1
(g21, _) = split g2
(g1, g2) = split g
</pre><p>
Since g1 and g2 are independent, g12 and g21 ought to be too. But they're not! If we use both of g12 and g21 to generate a random number in the range [0..10], then the two numbers ought to be equal 1/11 of the time. In fact, they're never equal.
Here is a test program that ought to return True 1/11 of the time but
actually always returns False:
</p>
<pre class="wiki">sample :: StdGen -> (Int, Int)
sample g = (fst (randomR (0, 10) g1),
fst (randomR (0, 10) g2))
where (g1, g2) = split' g
test :: StdGen -> Bool
test g = fst (sample g) == snd (sample g)
</pre><p>
I attached a program that prints the distribution of values from
<tt>test</tt> for other ranges than [0..10]. The distribution is
always quite bad no matter what the range is.
</p>
<p>
The upshot of all this is that the following QuickCheck (version 2)
property always passes, even though it's false:
</p>
<pre class="wiki">import Test.QuickCheck
import Text.Show.Functions
newtype Eleven = Eleven Int deriving Eq
instance Arbitrary Eleven where
arbitrary = fmap Eleven (choose (0, 10))
prop :: (Int -> Eleven) -> Bool
prop f = f 5 /= f 6
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3620#changelog
http://ghc.haskell.org/trac/ghc/ticket/3628
http://ghc.haskell.org/trac/ghc/ticket/3628#3628: exceptions reported to stderr when they propagate past forkIOFri, 30 Oct 2009 16:14:34 GMTduncan<p>
It's not entirely obvious what to do with exceptions that do not get handled within a <tt>forkIO</tt> however reporting them on stderr (or on Windows popping up a message dialog) does not seem right.
</p>
<p>
We do not have other cases where errors are logged to stderr. The only such case is an exception terminating Main.main (and that's special because it terminates the whole process). If it is vital that someone do something with exceptions in forkIO threads then they should be propagated to another thread, in the worst case the main thread.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3628#changelog
http://ghc.haskell.org/trac/ghc/ticket/3676
http://ghc.haskell.org/trac/ghc/ticket/3676#3676: realToFrac doesn't sanely convert between floating typesThu, 19 Nov 2009 03:46:40 GMTdraconx<p>
As far as I can tell, the only way to convert between floating types in Haskell is to use realToFrac. Unfortunately, this function does some insane mangling of values when converting. Some examples:
</p>
<pre class="wiki">realToFrac (0/0 :: Double) :: Double
--> -Infinity
realToFrac (-1/0 :: Float) :: Double
--> -3.402823669209385e38
realToFrac (-0 :: Double) :: CDouble
--> 0.0
</pre><p>
The last item illustrates an important point: it is impossible to convert a value from Double to CDouble without potentially changing it. This makes it difficult or impossible to use the FFI to call any functions with floating point parameters/return values.
</p>
<p>
Using a combination of unsafeCoerce (to shoehorn Double values in/out of CDoubles) and some functions written in C (to perform float<=>double), I was able to work around these problems, but that hardly seems like a nice solution.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3676#changelog
http://ghc.haskell.org/trac/ghc/ticket/5014
http://ghc.haskell.org/trac/ghc/ticket/5014#5014: canonicalizePath throws exception on paths that do not existFri, 11 Mar 2011 11:01:18 GMThesselink<p>
Assume path <tt>foo</tt> exists, but <tt>foo/bar</tt> doesn't. On GHC 6.12, <tt>canonicalizePath "foo/bar"</tt> gave back a result. On GHC 7.02, I get an exception:
</p>
<pre class="wiki">*** Exception: foo/bar: canonicalizePath: does not exist (No such file or directory)
</pre><p>
The behavior is not defined by the documentation, or at all (see <a class="upstream ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4215" title="bug: canonicalizePath behaves strangely with paths that do not exist (upstream)">#4215</a>) but it would be nice if it didn't crash.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5014#changelog
http://ghc.haskell.org/trac/ghc/ticket/5251
http://ghc.haskell.org/trac/ghc/ticket/5251#5251: copyFile does not copy metadataFri, 10 Jun 2011 12:26:33 GMTOrphi<p>
The <tt>copyFile</tt> function fails to copy various metadata to do with a file.
</p>
<p>
(GHC 7.0.2, directory 1.1.0.0 - not that I expect it to matter.)
</p>
<p>
The cause is simple: Rather than calling an OS-specific "please copy this file" function, the directory package attempts to implement this logic itself. And does it completely wrong.
</p>
<p>
The fix should be easy; we just need somebody to figure out what the appropriate native OS function is on each platform.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5251#changelog
http://ghc.haskell.org/trac/ghc/ticket/5278
http://ghc.haskell.org/trac/ghc/ticket/5278#5278: System.Random.randomIvalInteger makes invalid assumptions about RandomGenMon, 27 Jun 2011 01:46:31 GMTrrnewton<p>
The existing API for <tt>System.Random.RandomGen</tt> allows a random number generator (RNG) to produce Ints within an arbitrary range specified by <tt>genRange</tt>.
</p>
<p>
For example, the following <tt>RandomGen</tt> produces only zeros and ones, but should be legitimate:
</p>
<pre class="wiki">import System.Random
data BinRNG = BinRNG StdGen
instance RandomGen BinRNG where
next (BinRNG g) = (x `mod` 2, BinRNG g')
where (x,g') = next g
split (BinRNG g) = (BinRNG g1, BinRNG g2)
where (g1,g2) = split g
genRange _ = (0,1)
ls :: [Int]
ls = randoms (BinRNG$ mkStdGen 38388)
main = print $ take 20 ls
</pre><p>
But <tt>System.Random.randomIvalInteger</tt> makes invalid assumptions about the amount of randomness produced by <tt>next</tt>. (Specifically, assuming that it creates the same amount as <tt>StdGen</tt>.) Thus, the above program will create an output with only a couple of unique ints (rather than 2<sup>64).
</sup></p>
<p>
For example:
</p>
<pre class="wiki">[4611734781337924537,4611734781337924537,-9223323645458902796,
-9223323645458902797,4611734783485408099,4611734783485408098,
-9223323645458902796,-9223323647606386357,4611734781337924538,
-9223323645458902796,-9223323645458902797,
-9223323647606386357,4611734783485408098,4611734783485408098,
-9223323647606386357,4611734781337924538,4611734781337924537,
-9223323645458902796,4611734783485408099,4611734781337924538]
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5278#changelog
http://ghc.haskell.org/trac/ghc/ticket/5466
http://ghc.haskell.org/trac/ghc/ticket/5466#5466: Documentation for Chan could be betterWed, 07 Sep 2011 04:10:45 GMTpumpkin<p>
The summary is two words, and none of the operations say whether they block or not. Someone on reddit was expecting a read to throw an exception if the Chan was empty, for example.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5466#changelog
http://ghc.haskell.org/trac/ghc/ticket/5797
http://ghc.haskell.org/trac/ghc/ticket/5797#5797: readRawBufferPtr cannot be interrupted by exception on Windows with -threadedWed, 18 Jan 2012 11:17:52 GMTjoeyadams<p>
On Windows, in a program compiled with -threaded, if a thread receives from a Handle created by the network package (e.g. with hGetLine), it cannot be interrupted by an asynchronous exception.
</p>
<p>
I've traced it down to readRawBufferPtr, which is used by Network.Socket.recv. Although I haven't tested readRawBufferPtr directly, my test case (attached) tests Network.Socket.recv.
</p>
<p>
For Windows, base 4.4.1.0 implements it as:
</p>
<pre class="wiki">readRawBufferPtr :: String -> FD -> Ptr Word8 -> Int -> CSize -> IO CInt
readRawBufferPtr loc !fd buf off len
| threaded = blockingReadRawBufferPtr loc fd buf off len
| otherwise = asyncReadRawBufferPtr loc fd buf off len
...
blockingReadRawBufferPtr :: String -> FD -> Ptr Word8 -> Int -> CSize -> IO CInt
blockingReadRawBufferPtr loc fd buf off len
= fmap fromIntegral $ throwErrnoIfMinus1Retry loc $
if fdIsSocket fd
then c_safe_recv (fdFD fd) (buf `plusPtr` off) len 0
else c_safe_read (fdFD fd) (buf `plusPtr` off) len
...
-- NOTE: "safe" versions of the read/write calls for use by the threaded RTS.
-- These calls may block, but that's ok.
foreign import stdcall safe "recv"
c_safe_recv :: CInt -> Ptr Word8 -> CSize -> CInt{-flags-} -> IO CSsize
foreign import stdcall safe "send"
c_safe_send :: CInt -> Ptr Word8 -> CSize -> CInt{-flags-} -> IO CSsize
</pre><p>
If I understand correctly, safe foreign calls cannot be interrupted by asynchronous exceptions.
</p>
<p>
Is this a bug in readRawBufferPtr, or a bug in the network package? Can a caller expect readRawBufferPtr to be interruptible by an exception?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5797#changelog
http://ghc.haskell.org/trac/ghc/ticket/6101
http://ghc.haskell.org/trac/ghc/ticket/6101#6101: Show instance for integer-simple is not lazy enoughThu, 17 May 2012 00:22:19 GMTtommd<p>
I run out of memory, after 31 GB, when trying to show an Integer (using integer-simple) that is in the ballpark of 200K digits. I assume this is due to the entire string being generated at once and not lazily.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/6101#changelog
http://ghc.haskell.org/trac/ghc/ticket/7045
http://ghc.haskell.org/trac/ghc/ticket/7045#7045: The `Read` instance of `Rational` does not support decimal notationTue, 03 Jul 2012 08:17:13 GMTmaeder<pre class="wiki">main = print (1.10 :: Rational)
</pre><p>
is legal whereas
</p>
<pre class="wiki">main = print (read "1.10" :: Rational)
</pre><p>
fails at runtime with "Prelude.read: no parse"
</p>
<p>
The same applies to "1E10", but the e-notation should be rejected in both cases (see <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/7044" title="bug: reject reading rationals with exponent notation (new)">#7044</a>)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7045#changelog
http://ghc.haskell.org/trac/ghc/ticket/7309
http://ghc.haskell.org/trac/ghc/ticket/7309#7309: The Ix instance for (,) leaks space in rangeMon, 08 Oct 2012 13:55:17 GMTnomeata<p>
(at least if you take leak to mean unexpected space behaviour).
</p>
<p>
This was brought to my attention via <a class="ext-link" href="http://stackoverflow.com/questions/12780497/puzzling-memory-behavior-in-haskell"><span class="icon"></span>http://stackoverflow.com/questions/12780497/puzzling-memory-behavior-in-haskell</a> where someone created a <tt>6×10^6</tt>-array and was surprised that showing the array caused an additional <tt>(3+2)*8*10^6</tt> bytes to be used. The reason (as far as I could tell) was this code:
</p>
<pre class="wiki">instance (Ix a, Ix b) => Ix (a, b) where
range ((l1,l2),(u1,u2)) = [ (i1,i2) | i1 <- range (l1,u1), i2 <- range (l2,u2) ]
</pre><p>
in Arr.GHC. The result of <tt>range (l2,u2)</tt> is shared between every step in the first component of the index.
</p>
<p>
I guess it is reasonable to expect that the result of range is never worth sharing (is it?). I am not entirely sure what the best, cleanest, alternative implementation is, though. (At least not without a working <tt></tt><tt>dontshare</tt><tt></tt> annotation ;-))
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7309#changelog
http://ghc.haskell.org/trac/ghc/ticket/7353
http://ghc.haskell.org/trac/ghc/ticket/7353#7353: Make system IO interruptible on WindowsSat, 20 Oct 2012 16:50:22 GMTjoeyadams<p>
Currently, IO operations (connect, read, etc.) cannot be interrupted on Windows. Additionally, threadWaitRead and threadWaitWrite do not work on Windows (IIRC, they can't tell if the given file descriptor is a socket or not, so they assume it's not).
</p>
<p>
The reason is that GHC does not have an IO manager for Windows like it does for *nix. For Windows with -threaded, the network package uses blocking FFI calls, which cannot be interrupted by asynchronous exceptions. Thus, System.Timeout and killThread can't be used to time out and interrupt network IO.
</p>
<p>
I'm working on a program that needs to run on a Windows XP machine for long periods of time, interacting with a couple intermittent network services. This issue is making things very difficult for me, so I want to get it fixed. I do not need to support thousands of concurrent connections efficiently; I just need my program to run reliably.
</p>
<p>
What needs to happen for IO to be interruptible on Windows with -threaded ? I'm willing to put in the work, but there's a lot I'd have to learn about windows IO and GHC IO handling. One question to get started: are threadWaitRead/threadWaitWrite even possible to implement on Windows, or might Windows assign overlapping HANDLE numbers to sockets and regular files?
</p>
<p>
This issue spans both GHC and the network package, but I'd like to collect information about it in one place. Related issues:
</p>
<ul><li><a class="ext-link" href="http://trac.haskell.org/network/ticket/2"><span class="icon"></span>http://trac.haskell.org/network/ticket/2</a>
</li></ul><ul><li><a class="ext-link" href="https://github.com/haskell/network/issues/36"><span class="icon"></span>https://github.com/haskell/network/issues/36</a>
</li></ul><ul><li><a class="ext-link" href="http://hackage.haskell.org/trac/ghc/ticket/3937"><span class="icon"></span>http://hackage.haskell.org/trac/ghc/ticket/3937</a>
</li></ul><ul><li><a class="ext-link" href="http://hackage.haskell.org/trac/ghc/ticket/5797"><span class="icon"></span>http://hackage.haskell.org/trac/ghc/ticket/5797</a>
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/7353#changelog
http://ghc.haskell.org/trac/ghc/ticket/7634
http://ghc.haskell.org/trac/ghc/ticket/7634#7634: MD5 collision could lead to SafeHaskell violationMon, 28 Jan 2013 08:55:55 GMTshachaf<p>
The current scheme for computing <tt>TypeRep</tt> fingerprints is: <tt>md5sum (encodeUTF32BE (unwords [moduleName, packageName, typeName]))</tt>. <tt>SafeHaskell</tt> doesn't allow custom-written <tt>Typeable</tt> instances, but this is more or less the code that <tt>deriving Typeable</tt> generates.
</p>
<p>
MD5 is broken and not collision-resistant. If someone can make an MD5 collision, they could use it to derive <tt>unsafeCoerce</tt> and execute arbitrary code. The constraints (UTF-32, names being alphanumeric, etc.) make it pretty tricky to find a valid collision by the standard methods, but I don't know enough about this to say how feasible it is.
</p>
<p>
It seems to me that, especially with <tt>new-typeable</tt>, it might not be necessary to use hashing at all, if GHC can figure out fingerprints statically. Or maybe separate compilation requirements make that unworkable (in which case maybe using a hash of the package/module name along with a separate per-module counter, or something along those lines, might be better, since people are less likely to control those? I'm not sure). Maybe the solution is just switching to another hash function, or something else. At any rate, the issue should be considered -- using MD5 isn't a good idea in cases where collisions could have security implications.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7634#changelog
http://ghc.haskell.org/trac/ghc/ticket/8293
http://ghc.haskell.org/trac/ghc/ticket/8293#8293: user001 spuriously fails if getGroupEntryForID correctly failsSat, 14 Sep 2013 05:58:42 GMTezyang<p>
In some cases, a user's current group ID can be a number for a non-existent group. While this usually indicates the system is misconfigured in some way, it can also occur inside chroots or other environments where the information in /etc/groups is not to be considered reliable. Unfortunately, the user001 has no way of telling that the failure is proper, and fails the test anyway. We ought to do something more robust.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8293#changelog
http://ghc.haskell.org/trac/ghc/ticket/8532
http://ghc.haskell.org/trac/ghc/ticket/8532#8532: Hyperbolic arc cosine fails on (-1) :: Complex r.Thu, 14 Nov 2013 12:00:11 GMTleftaroundabout<p>
When allowing for complex results, the hyperbolic arc cosine is continuously defined on all ℝ.
</p>
<p>
In the <tt>(x < (-1))</tt> real ray of the complex plane, <tt>acosh</tt> equals <tt>\z -> i * pi + acosh(abs z)</tt>, which works fine for almost all arguments. Thus, <tt>acosh (-1)</tt> should equal <tt>i * pi</tt>; however due to the implementation as
</p>
<pre class="wiki">acosh z = log (z + (z+1) * sqrt ((z-1)/(z+1)))
</pre><p>
where the denominator in the root becomes zero at <tt>z = -1</tt>, this comes out as <tt>NaN :+ NaN</tt>.
</p>
<p>
Could be fixed trivially by adding a special case
</p>
<pre class="wiki">acosh ((-1):+0) = 0:+pi
</pre><p>
to the <tt>instance (RealFloat a) => Floating (Complex a)</tt> in <tt>Data.Complex</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8532#changelog
http://ghc.haskell.org/trac/ghc/ticket/8627
http://ghc.haskell.org/trac/ghc/ticket/8627#8627: mallocForeignPtrBytes documentation unobvious regarding memory alignmentTue, 24 Dec 2013 00:44:31 GMTschernichkin<p>
According to the current documentation:
</p>
<p>
mallocForeignPtr - is equivalent to do { p <- malloc; newForeignPtr finalizerFree p }. It's ok since we can read that the "block of memory is sufficiently aligned" if the mallocBytes function descriprion and newAlignedPinnedByteArray in the function implementation.
</p>
<p>
mallocForeignPtrBytes - "similar to mallocForeignPtr" but will it alloc aligned memory? Internally it uses newPinnedByteArray which implies memory will not be aligned, but does it really makes any sense?
</p>
<p>
Plz correct documentation to make it more obvious.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8627#changelog
http://ghc.haskell.org/trac/ghc/ticket/8666
http://ghc.haskell.org/trac/ghc/ticket/8666#8666: integer-gmp fails to compile on Debian SqueezeMon, 13 Jan 2014 12:01:56 GMTjstolarek<p>
I get an error when compiling recent HEAD on Debian Squeeze:
</p>
<pre class="wiki">"inplace/bin/ghc-stage1" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H64m -O0 -fasm -package-name integer-gmp-0.5.1.0 -hide-all-packages -i -ilibraries/integer-gmp/. -ilibraries/integer-gmp/dist-install/build -ilibraries/integer-gmp/dist-install/build/autogen -Ilibraries/integer-gmp/dist-install/build -Ilibraries/integer-gmp/dist-install/build/autogen -Ilibraries/integer-gmp/. -optP-include -optPlibraries/integer-gmp/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -Wall -package-name integer-gmp -XHaskell2010 -O -fasm -no-user-package-db -rtsopts -Ilibraries/integer-gmp/mkGmpDerivedConstants/dist -odir libraries/integer-gmp/dist-install/build -hidir libraries/integer-gmp/dist-install/build -stubdir libraries/integer-gmp/dist-install/build -fno-use-rpaths -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-prim-0.3.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../rts-1.0' -optl-Wl,-zorigin libraries/integer-gmp/dist-install/build/GHC/Integer.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Internals.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Prim.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/Logarithms.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/Logarithms/Internals.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/Type.dyn_o libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.dyn_o libraries/integer-gmp/dist-install/build/cbits/cbits.dyn_o libraries/integer-gmp/gmp/objs/*.o -shared -dynamic -dynload deploy -no-auto-link-packages -o libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0-ghc7.7.20140113.so
Warning: -rtsopts and -with-rtsopts have no effect with -shared.
Call hs_init_ghc() from your main() function to set these options.
/usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation R_X86_64_32 against `__gmpz_sub' can not be used when making a shared object; recompile with -fPIC
libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0-ghc7.7.20140113.so] Error 1
make: *** [all] Error 2
</pre><p>
I can build in-tree <tt>libgmp</tt> by extracting it and running <tt>./configure make</tt>. Following Austin's and Herbert's suggestions I tried adding <tt>-fPIC</tt> to command line options but with no result - see attachements.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8666#changelog
http://ghc.haskell.org/trac/ghc/ticket/8730
http://ghc.haskell.org/trac/ghc/ticket/8730#8730: Invalid Unicode Codepoints in CharMon, 03 Feb 2014 07:23:23 GMTmdmenzel<p>
The surrogate range in Unicode is supposed to (as of Unicode 2.0, 1996) be a range of invalid code points yet, Data.Char allows the use of values in this range (in fact, it even gives them their own GeneralCategory).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8730#changelog
http://ghc.haskell.org/trac/ghc/ticket/8859
http://ghc.haskell.org/trac/ghc/ticket/8859#8859: import conditionalization in System.Posix.Files.Common is wrongSat, 08 Mar 2014 01:54:07 GMTrwbarton<p>
<tt>System/Posix/Files/Common.hsc</tt> imports <tt>Data.Int</tt> and <tt>Data.Ratio</tt> conditionally, to avoid "unused import" compiler warnings:
</p>
<pre class="wiki">#if defined(HAVE_STRUCT_STAT_ST_CTIM) || \
defined(HAVE_STRUCT_STAT_ST_MTIM) || \
defined(HAVE_STRUCT_STAT_ST_ATIM) || \
defined(HAVE_STRUCT_STAT_ST_ATIMESPEC) || \
defined(HAVE_STRUCT_STAT_ST_MTIMESPEC) || \
defined(HAVE_STRUCT_STAT_ST_CTIMESPEC)
import Data.Int
import Data.Ratio
#endif
</pre><p>
but those modules are actually used in functions like
</p>
<pre class="wiki">accessTimeHiRes (FileStatus stat) =
unsafePerformIO $ withForeignPtr stat $ \stat_ptr -> do
sec <- (#peek struct stat, st_atime) stat_ptr :: IO EpochTime
#ifdef HAVE_STRUCT_STAT_ST_ATIM
nsec <- (#peek struct stat, st_atim.tv_nsec) stat_ptr :: IO (#type long)
let frac = toInteger nsec % 10^(9::Int)
#elif HAVE_STRUCT_STAT_ST_ATIMESPEC
nsec <- (#peek struct stat, st_atimespec.tv_nsec) stat_ptr :: IO (#type long)
let frac = toInteger nsec % 10^(9::Int)
#elif HAVE_STRUCT_STAT_ST_ATIMENSEC
nsec <- (#peek struct stat, st_atimensec) stat_ptr :: IO (#type long)
let frac = toInteger nsec % 10^(9::Int)
#elif HAVE_STRUCT_STAT_ST_ATIME_N
nsec <- (#peek struct stat, st_atime_n) stat_ptr :: IO (#type int)
let frac = toInteger nsec % 10^(9::Int)
#elif HAVE_STRUCT_STAT_ST_UATIME
usec <- (#peek struct stat, st_uatime) stat_ptr :: IO (#type int)
let frac = toInteger usec % 10^(6::Int)
#else
let frac = 0
#endif
return $ fromRational $ toRational sec + frac
</pre><p>
so there should be additional tests for <tt>defined(HAVE_STRUCT_STAT_ST_ATIMENSEC)</tt>, <tt>defined(HAVE_STRUCT_STAT_ST_ATIME_N)</tt>, ... (15 total).
</p>
<p>
Or, maybe there's a better alternative, since this is very long-winded and fragile...
</p>
<p>
This breaks the build on Android, which has <tt>st_atimensec</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8859#changelog
http://ghc.haskell.org/trac/ghc/ticket/9044
http://ghc.haskell.org/trac/ghc/ticket/9044#9044: createDirectoryIfMissing does not fail on unwritable parent dirSun, 27 Apr 2014 23:22:34 GMTduncan<p>
On OSX, using <tt>createDirectoryIfMissing</tt> to create a new directory inside a directory for which we do not have write permissions does not throw any exception. Of course it should throw an exception, as it does under Linux.
</p>
<pre class="wiki">$ mkdir unwritable
$ chmod ugo-w unwritable
$ ghci
> System.Directory.createDirectoryIfMissing True "unwritable/tst"
>
</pre><p>
On OSX (10.9.2) this does not fail. Under Linux (albeit with 7.6.3) this does throw an exception as expected:
</p>
<pre class="wiki">*** Exception: unwritable/tst: createDirectory: permission denied (Permission denied)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/9044#changelog
http://ghc.haskell.org/trac/ghc/ticket/9079
http://ghc.haskell.org/trac/ghc/ticket/9079#9079: Foreign.C.Types in haskell2010Mon, 05 May 2014 20:05:54 GMTtensor5<p>
According to Haskell 2010, a marshallable foreign type has to be a <tt>newtype</tt> of a basic type with exposed constructor. Why constructors are not exposed in the module <tt>Foreign.C.Types</tt> from <tt>haskell2010</tt>?
When I replace <tt>base</tt> with <tt>haskell2010</tt> in
</p>
<pre class="wiki">module Test where
import Foreign.C
foreign import ccall unsafe "sys/mount.h umount" umount :: CString -> IO CInt
</pre><p>
I get
</p>
<pre class="wiki">Unacceptable result type in foreign declaration: IO CInt
When checking declaration:
foreign import ccall unsafe "static sys/mount.h umount" umount
:: CString -> IO CInt
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/9079#changelog
http://ghc.haskell.org/trac/ghc/ticket/9283
http://ghc.haskell.org/trac/ghc/ticket/9283#9283: bad autoconf variable namesMon, 07 Jul 2014 17:43:47 GMTrwbarton<pre class="wiki">if test "$ac_cv_header_sys_epoll_h" = yes -a "$ac_cv_func_epoll_ctl" = yes; then
AC_DEFINE([HAVE_EPOLL], [1], [Define if you have epoll support.])
fi
if test "$ac_cv_header_sys_event_h" = yes -a "$ac_cv_func_kqueue" = yes; then
AC_DEFINE([HAVE_KQUEUE], [1], [Define if you have kqueue support.])
AC_CHECK_SIZEOF([kev.filter], [], [#include <sys/event.h>
struct kevent kev;])
AC_CHECK_SIZEOF([kev.flags], [], [#include <sys/event.h>
struct kevent kev;])
fi
if test "$ac_cv_header_poll_h" = yes -a "$ac_cv_func_poll" = yes; then
AC_DEFINE([HAVE_POLL], [1], [Define if you have poll support.])
fi
</pre><p>
The <tt>AC_DEFINE</tt> lines for <tt>HAVE_KQUEUE</tt> and <tt>HAVE_POLL</tt> don't do anything, because earlier we have
</p>
<pre class="wiki">AC_CHECK_FUNCS([epoll_ctl eventfd kevent kevent64 kqueue poll])
</pre><p>
and that already defines <tt>HAVE_KQUEUE</tt> (and sets <tt>ac_cv_func_kqueue</tt>) when the <tt>kqueue</tt> function is found.
</p>
<p>
Not entirely sure what the right thing to do is here, do we rely on having a prototype for <tt>kqueue</tt> in <tt>sys/event.h</tt> specifically? Technically that wouldn't be what we check for even if we used a renamed <tt>HAVE_KQUEUE</tt> variable.
</p>
<p>
AFAIK this doesn't cause any real problems except that it really confused me when I tried to simulate not having <tt>poll</tt> by moving <tt>/usr/include/poll.h</tt> away temporarily.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9283#changelog
http://ghc.haskell.org/trac/ghc/ticket/9292
http://ghc.haskell.org/trac/ghc/ticket/9292#9292: Race condition when multiple threads wait for a processThu, 10 Jul 2014 16:17:14 GMTsnoyberg<p>
Consider the following code:
</p>
<pre class="wiki">import System.Process
import Control.Concurrent.Async
main :: IO ()
main = do
(_, _, _, ph) <- createProcess $ shell "sleep 1"
let helper i = do
ec <- waitForProcess ph
print (i :: Int, ec)
((), ()) <- concurrently (helper 1) (helper 2)
return ()
</pre><p>
If I compile with the single threaded runtime, I get the output
</p>
<pre class="wiki">(2,ExitSuccess)
(1,ExitSuccess)
</pre><p>
But when compiling with the multithreaded runtime, I get:
</p>
<pre class="wiki">bin: waitForProcess: does not exist (No child processes)
</pre><p>
If you need to wait for a process from multiple threads, you can do so now by having a dedicated wait thread which writes to an MVar or TMVar, but the current default behavior can be surprising.
</p>
<p>
I discussed this in a <a class="ext-link" href="http://www.yesodweb.com/blog/2014/07/rfc-new-data-conduit-process"><span class="icon"></span>blog post</a>, and there was some <a class="ext-link" href="http://www.reddit.com/r/haskell/comments/2abmwu/rfc_new_dataconduitprocess/cithh69"><span class="icon"></span>conversation on Reddit</a>.
</p>
<p>
At the least, I think we need better documentation, but if there's a better solution, that would be best.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9292#changelog
http://ghc.haskell.org/trac/ghc/ticket/9306
http://ghc.haskell.org/trac/ghc/ticket/9306#9306: Crash when shifting Integers too far leftSun, 13 Jul 2014 08:07:17 GMTdfeuer<p>
When shifting an Integer very far left, the RTS crashes. On x86_64:
</p>
<p>
Prelude Data.Bits> 1 <tt>shiftL</tt> 100000000000000000000000 == 1
gmp: overflow in mpz type
Aborted
</p>
<p>
I found the bug in 7.6.3, but it's been verified to be present also in 7.8.3. The crash also occurs when running similar code compiled by ghc.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9306#changelog
http://ghc.haskell.org/trac/ghc/ticket/9539
http://ghc.haskell.org/trac/ghc/ticket/9539#9539: TQueue can lead to thread starvationMon, 01 Sep 2014 23:52:14 GMTjwlato<p>
For background, please see <a class="ext-link" href="http://stackoverflow.com/questions/25536604/huge-memory-consumption-for-simple-multithreaded-haskell/25560047#25560047"><span class="icon"></span>this SO question</a>
</p>
<p>
When using TQueue, a sufficiently fast/persistent writer can result in the reader never getting scheduled, causing the queue to continually grow and lost concurrency.
</p>
<p>
I believe the issue is caused by the definition of readTQueue:
</p>
<pre class="wiki">readTQueue :: TQueue a -> STM a
readTQueue (TQueue read write) = do
xs <- readTVar read
case xs of
(x:xs') -> do writeTVar read xs'
return x
[] -> do ys <- readTVar write
case ys of
[] -> retry
_ -> case reverse ys of
[] -> error "readTQueue"
(z:zs) -> do writeTVar write []
writeTVar read zs
return z
</pre><p>
Note that the last <tt>case</tt> needs to traverse the write-end of the queue within the STM transaction. If the list is sufficiently large, a writer can commit a new transaction much more quickly, invalidating the read transaction. If threads continue to write to the queue, the reader will never get an opportunity to commit (and the list will grow, exacerbating the problem).
</p>
<p>
This alternative definition seems to fix the problem, but I don't know if there are other drawbacks to using it.
</p>
<pre class="wiki">readTQueue' :: TQueue a -> STM a
readTQueue' (TQueue read write) = do
xs <- readTVar read
case xs of
(x:xs') -> do writeTVar read xs'
return x
[] -> do ys <- readTVar write
case ys of
[] -> retry
_ -> do writeTVar write []
let (z:zs) = reverse ys
writeTVar read zs
return z
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/9539#changelog
http://ghc.haskell.org/trac/ghc/ticket/9631
http://ghc.haskell.org/trac/ghc/ticket/9631#9631: Comment in GHC.Base about GHC.Prim does not appear to be correctThu, 25 Sep 2014 06:31:15 GMTdfeuer<p>
The comment reads
</p>
<pre class="wiki">GHC.Prim Has no implementation. It defines built-in things, and
by importing it you bring them into scope.
The source file is GHC.Prim.hi-boot, which is just
copied to make GHC.Prim.hi
</pre><p>
It does not appear that any files by these names exist.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9631#changelog
http://ghc.haskell.org/trac/ghc/ticket/9792
http://ghc.haskell.org/trac/ghc/ticket/9792#9792: map/coerce rule does not fire until the coercion is knownTue, 11 Nov 2014 02:37:08 GMTdfeuer<p>
If I write a nice, simple use, like:
</p>
<div class="code"><pre><span class="nf">myPotato</span> <span class="ow">=</span> map coerce
</pre></div><p>
or even
</p>
<div class="code"><pre><span class="nf">myPotato</span> <span class="ow">=</span> <span class="kt">Data</span><span class="o">.</span><span class="kt">OldList</span><span class="o">.</span>map coerce
</pre></div><p>
the "<tt>map/coerce</tt>" rule does not fire.
</p>
<p>
It looks like there are two things getting in the way:
</p>
<ol><li>The <tt>map</tt> rule fires first, turning <tt>map</tt> into a <tt>build/foldr</tt> form, which <tt>map/coerce</tt> does not recognize.
</li></ol><ol start="2"><li>Even if <tt>map</tt> gets written back, <tt>coerce</tt> has been expanded into something the rule doesn't recognize.
</li></ol><p>
So we end up with something that looks like
</p>
<div class="code"><pre><span class="nf">myPotato</span> <span class="ow">=</span>
<span class="nf">\</span> <span class="p">(</span><span class="o">@</span> a_are<span class="p">)</span>
<span class="p">(</span><span class="o">@</span> b_arf<span class="p">)</span>
<span class="p">(</span><span class="o">$</span>dCoercible_arz <span class="ow">::</span> <span class="kt">Coercible</span> a_are b_arf<span class="p">)</span>
<span class="p">(</span>lst_aqx <span class="ow">::</span> <span class="p">[</span>a_are<span class="p">])</span> <span class="ow">-></span>
map
<span class="o">@</span> a_are
<span class="o">@</span> b_arf
<span class="p">(</span><span class="nf">\</span> <span class="p">(</span>tpl_B2 <span class="p">[</span><span class="kt">OS</span><span class="ow">=</span><span class="kt">ProbOneShot</span><span class="p">]</span> <span class="ow">::</span> a_are<span class="p">)</span> <span class="ow">-></span>
<span class="kr">case</span> <span class="o">$</span>dCoercible_arz
<span class="kr">of</span> <span class="kr">_</span> <span class="p">[</span><span class="kt">Occ</span><span class="ow">=</span><span class="kt">Dead</span><span class="p">]</span> <span class="p">{</span> <span class="kt">GHC</span><span class="o">.</span><span class="kt">Types</span><span class="o">.</span><span class="kt">MkCoercible</span> tpl1_B3 <span class="ow">-></span>
tpl_B2 <span class="p">`</span>cast<span class="p">`</span> <span class="p">(</span>tpl1_B3 <span class="ow">::</span> a_are <span class="o">~</span><span class="kt">R</span><span class="o">#</span> b_arf<span class="p">)</span>
<span class="p">})</span>
lst_aqx
</pre></div>Resultshttp://ghc.haskell.org/trac/ghc/ticket/9792#changelog
http://ghc.haskell.org/trac/ghc/ticket/10034
http://ghc.haskell.org/trac/ghc/ticket/10034#10034: Regression in mapM_ performanceTue, 27 Jan 2015 17:56:18 GMTdfeuer<p>
The current <tt>mapM_</tt> is sometimes worse than the version in 7.8.3. This can be fixed easily by eta-expansion, matching <tt>mapM</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/10034#changelog
http://ghc.haskell.org/trac/ghc/ticket/10092
http://ghc.haskell.org/trac/ghc/ticket/10092#10092: lex doesn't handle binary literalsSun, 15 Feb 2015 22:46:01 GMTRyanGlScott<p>
The <tt>lex</tt> function from <tt>Text.Read.Lex</tt> (on which the <tt>Read</tt> instance for <tt>Lexeme</tt> is based) can't read binary literals on GHC 7.10.1-rc2:
</p>
<pre class="wiki">$ ghci -XBinaryLiterals
GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help
λ> 0b101010
42
λ> import Text.Read.Lex
λ> read "0b101010" :: Lexeme
*** Exception: Prelude.read: no parse
</pre><p>
This should be a simple fix, but I'm not sure if this is the intended behavior or not, since <tt>BinaryLiterals</tt> isn't a part of the Haskell 2010 standard (and I'm not sure how closely <tt>lex</tt> adheres to that).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/10092#changelog
http://ghc.haskell.org/trac/ghc/ticket/9886
http://ghc.haskell.org/trac/ghc/ticket/9886#9886: Undefined reference to `__sync_fetch_and_xor_8'Mon, 15 Dec 2014 00:02:58 GMTerikd<p>
Compiling on PowerPC with git head (0c9c2d899e63b810), compile terminates with:
</p>
<pre class="wiki">/home/ghc-upstream/libraries/ghc-prim/dist-install/build/
libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined
reference to `__sync_fetch_and_xor_8'
/home/ghc-upstream/libraries/ghc-prim/dist-install/build/
libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined
reference to `__sync_fetch_and_and_8'
/home/ghc-upstream/libraries/ghc-prim/dist-install/build/
libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined
reference to `__sync_fetch_and_nand_8'
/home/ghc-upstream/libraries/ghc-prim/dist-install/build/
libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined
reference to `__sync_val_compare_and_swap_8'
/home/ghc-upstream/libraries/ghc-prim/dist-install/build/
libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined
reference to `__sync_fetch_and_sub_8'
/home/ghc-upstream/libraries/ghc-prim/dist-install/build/
libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined
reference to `__sync_fetch_and_add_8'
/home/ghc-upstream/libraries/ghc-prim/dist-install/build/
libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined
reference to `__sync_fetch_and_or_8'
</pre><p>
Looks like some new primops that need to be implemented for powerpc.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9886#changelog
http://ghc.haskell.org/trac/ghc/ticket/10070
http://ghc.haskell.org/trac/ghc/ticket/10070#10070: Cross compiling from Linux to Windows fails with mising Win32 libraryMon, 09 Feb 2015 10:14:53 GMTerikd<p>
After applying the proposed patch from <a class="patch ticket" href="http://ghc.haskell.org/trac/ghc/ticket/9524" title="bug: GHC uses wrong linker when cross compiling (patch)">#9524</a>, building a Linux to Windows cross-compiler terminates with:
</p>
<pre class="wiki">Configuring time-1.5.0.1...
ghc-cabal: At least the following dependencies are missing:
Win32 -any
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/10070#changelog
http://ghc.haskell.org/trac/ghc/ticket/8488
http://ghc.haskell.org/trac/ghc/ticket/8488#8488: Annotations should not distinguish type and valueWed, 30 Oct 2013 09:01:50 GMTsimonpj<p>
In <tt>HsDecls</tt> we have
</p>
<pre class="wiki">data AnnDecl name = HsAnnotation (AnnProvenance name) (Located (HsExpr name))
data AnnProvenance name = ValueAnnProvenance name
| TypeAnnProvenance name
| ModuleAnnProvenance
</pre><p>
And there's now a similar 3-way distinction in Template Haskell <tt>Syntax</tt>:
</p>
<pre class="wiki">data AnnTarget = ModuleAnnotation
| TypeAnnotation Name
| ValueAnnotation Name
</pre><p>
But there's really no need to distinguish between <tt>TypeAnnProvenance</tt> and <tt>ValueAnnProvenance</tt> (and similarly in the TH vesrion) because the namespace on the <tt>Name</tt> makes that distinction. So the current story is redundant, and hence has silly case where you have a <tt>ValueAnnProvenance</tt> on a type constructor.
</p>
<p>
Better to collapse the two. I'm making this a ticket so that people can comment. I hope that Gergely may be able to do it as part of his TH/annotation work.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8488#changelog
http://ghc.haskell.org/trac/ghc/ticket/367
http://ghc.haskell.org/trac/ghc/ticket/367#367: Infinite loops can hang Concurrent HaskellTue, 26 Apr 2005 07:35:26 GMTsimonpj<pre class="wiki">An infinite loop that does not allocate can hang
Concurrent Haskell, becuase no thread switching
occurs. Demo code below (from Koen Claessen).
Bites occasionally, but not often.
Simon
module Main where
import Control.Concurrent
( forkIO
, threadDelay
, killThread
, newEmptyMVar
, takeMVar
, putMVar
)
import Data.IORef
import IO( hFlush, stdout )
timeout :: Int -> a -> IO (Maybe a)
timeout n x =
do put "Race starts ..."
resV <- newEmptyMVar
pidV <- newEmptyMVar
let waitAndFail =
do put "Waiting ..."
threadDelay n
put "Done waiting!"
putMVar resV Nothing
eval =
do put "Evaluating ..."
x `seq` put "Done!"
putMVar resV (Just x)
-- used "mfix" here before but got non-termination
problems
-- (not sure they had anything to do with mfix)
pid1 <- forkIO $ do pid2 <- takeMVar pidV
eval
killThread pid2
pid2 <- forkIO $ do waitAndFail
killThread pid1
putMVar pidV pid2
put "Blocking ..."
takeMVar resV
put s =
do putStrLn s
hFlush stdout
main =
do timeout 1 (sum (repeat 1))
<<<
The above program produces the following (expected
result):
>>>
Race starts ...
Blocking ...
Evaluating ...
Waiting ...
Done waiting!
<<<
If you replace 'sum (repeat 1)' by 'last (repeat 1)' the
program hangs.
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/367#changelog
http://ghc.haskell.org/trac/ghc/ticket/7831
http://ghc.haskell.org/trac/ghc/ticket/7831#7831: Bad fragmentation when allocating many large objectsSat, 13 Apr 2013 09:17:23 GMTezyang<p>
Consider our good old friend, the space-leaky list program:
</p>
<pre class="wiki">import Control.Exception
import System.Environment
f n = let xs = [1..n] in sum xs * product xs
main = do
[n] <- getArgs
evaluate (f (read n :: Integer))
</pre><p>
It is not surprising that this program is quite the memory guzzler; what is surprising is how much GHC *wastes* when evaluating this program:
</p>
<pre class="wiki">Fragmentation, wanted 95 blocks, 105 MB free
</pre><p>
(For reference, a block is 4k, so 95 blocks is a measly 380k!) The magnitude of the problem can be seen in this graphic:
</p>
<p>
<a style="padding:0; border:none" href="http://web.mit.edu/~ezyang/Public/fragmentation-ghc.png"><img src="http://web.mit.edu/~ezyang/Public/fragmentation-ghc.png" alt="http://web.mit.edu/~ezyang/Public/fragmentation-ghc.png" title="http://web.mit.edu/~ezyang/Public/fragmentation-ghc.png" /></a>
</p>
<p>
(The x-axis takes advantage of the fact that the number of requested blocks increases ~linearly over time, since we keep multiplying the integer which adds a constant number of extra bytes to the representation; unused free memory corresponds to blocks of free memory in GHC's free list, which it is holding onto from the OS but not using to store user data.)
</p>
<p>
When the requested allocations are *just* large enough (just slightly over half a megablock, or 128 blocks), we start allocating a megablock per allocation and waste half of the megablock, since none of the leftovers are ever large enough to store any of the later allocations.
</p>
<p>
Can we do anything about this? One possibility is to occasionally check how much space we're losing to fragmentation, and everyone once in a while pay the cost of copying tenured large objects and pack them together in a megablock group (obviously one wants to avoid doing this too often, since copying large objects is expensive!) I'm open to better suggestions though! (Apologies if this is a duplicate; I didn't see any open tickets with the word "fragmentation" in them).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7831#changelog
http://ghc.haskell.org/trac/ghc/ticket/9225
http://ghc.haskell.org/trac/ghc/ticket/9225#9225: Missing syntax error for package qualified import with version numberSun, 22 Jun 2014 16:30:19 GMTezyang<p>
Consider the following test file:
</p>
<pre class="wiki">{-# LANGUAGE PackageImports #-}
module Foo where
import "containers-0.5.0.0" Data.Map
</pre><p>
where we have
</p>
<pre class="wiki">ezyang@sabre:~$ ghc-pkg list | grep containers
containers-0.5.0.0
unordered-containers-0.2.3.0
</pre><p>
GHC will fail to compile this, but in an unusual way:
</p>
<pre class="wiki">ezyang@sabre:~$ ghc test.hs
[1 of 1] Compiling Foo ( test.hs, test.o )
test.hs:3:1:
Failed to load interface for `Data.Map'
It is not a module in the current program, or in any known package.
</pre><p>
That's misleading: the real reason the import failed is because this is a package qualified import (not package ID qualified imports). For my purposes, it would be useful to also support package ID imports, but in the meantime, it would be a good idea to run Cabal's syntax check on the package name, which requires every hyphenated component to contain an alphabetic character.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9225#changelog
http://ghc.haskell.org/trac/ghc/ticket/9651
http://ghc.haskell.org/trac/ghc/ticket/9651#9651: Increasing verbosity doesn't give useful information for why we couldn't load packageTue, 30 Sep 2014 21:03:32 GMTezyang<p>
I don't time to fix this now, so recording so I remember.
</p>
<pre class="wiki">[ezyang@hs01 ghc-nocode]$ /home/hs01/ezyang/ghc-head/inplace/bin/ghc-stage2 -package-key ghc_GE0xPzNsQzT2p10hpwDwSW --interactive -package-db libraries/bootstrapping.conf -v
GHCi, version 7.9.20140929: http://www.haskell.org/ghc/ :? for help
Glasgow Haskell Compiler, Version 7.9.20140929, stage 2 booted by GHC version 7.8.3
Using binary package database: /home/hs01/ezyang/ghc-head/inplace/lib/package.conf.d/package.cache
Using binary package database: libraries/bootstrapping.conf/package.cache
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting:
<command line>: cannot satisfy -package-key ghc_GE0xPzNsQzT2p10hpwDwSW
(use -v for more information)
[ezyang@hs01 ghc-nocode]$ /home/hs01/ezyang/ghc-head/inplace/bin/ghc-stage2 -package-key ghc_GE0xPzNsQzT2p10hpwDwSW --interactive -package-db libraries/bootstrapping.conf
GHCi, version 7.9.20140929: http://www.haskell.org/ghc/ :? for help
<command line>: cannot satisfy -package-key ghc_GE0xPzNsQzT2p10hpwDwSW
(use -v for more information)
[ezyang@hs01 ghc-nocode]$ /home/hs01/ezyang/ghc-head/inplace/bin/ghc-stage2 -package-key ghc_GE0xPzNsQzT2p10hpwDwSW --interactive -package-db libraries/bootstrapping.conf -v
GHCi, version 7.9.20140929: http://www.haskell.org/ghc/ :? for help
Glasgow Haskell Compiler, Version 7.9.20140929, stage 2 booted by GHC version 7.8.3
Using binary package database: /home/hs01/ezyang/ghc-head/inplace/lib/package.conf.d/package.cache
Using binary package database: libraries/bootstrapping.conf/package.cache
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting:
<command line>: cannot satisfy -package-key ghc_GE0xPzNsQzT2p10hpwDwSW
(use -v for more information)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/9651#changelog
http://ghc.haskell.org/trac/ghc/ticket/9717
http://ghc.haskell.org/trac/ghc/ticket/9717#9717: More lazy orphan module loadingFri, 24 Oct 2014 01:46:32 GMTezyang<p>
Currently, when we import a module, we eagerly load all of the orphan modules transitively reachable from it (TcRnDriver:tcRnImports). This is a bit of bummer: as module import hierarchies get deeper and deeper, we'll collect more and more orphan instances and load more and more modules eagerly.
</p>
<p>
The idea is to try to arrange for an orphan module not to be loaded, unless we think that it might have a relevant instance. Instead of just recording a list of orphan modules transitively reachable from a module, we will also record a digest of what type classes and types the orphan provides instances for. (This will be similar to the data we record for <tt>ifInstTys</tt> in <tt>IfaceClsInst</tt>.)
</p>
<p>
Now, when we do any operation involving instances, we check and see if there are also orphans which could provide relevant instances (based on the digest) and load those. If an instance could never have been used, we avoid loading its interface file entirely.
</p>
<p>
This doesn't appear to help too much for type families, where we have to load all of the instances anyway in order to check for consistency.
</p>
<p>
A choice to make: Should we record just the class, or also the types involved? It would be best if we could quickly conclude that there are no more instances to load, but this may be difficult if matching against types as well.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9717#changelog
http://ghc.haskell.org/trac/ghc/ticket/9956
http://ghc.haskell.org/trac/ghc/ticket/9956#9956: Command line flag deprecated warning could be annoying for -Werror usersSun, 04 Jan 2015 18:52:18 GMTezyang<p>
In 7.10 we deprecated the poorly named <tt>-package-name</tt> for <tt>-this-package-key</tt>. However, I was working with GHC's validate script and I noticed that this behavior actually might be pretty annoying, because it causes GHC to fail on <tt>-Werror</tt>, and there doesn't seem to be any way of turning off this behavior.
</p>
<p>
So maybe we should add a -fno-warn flag which controls flag warnings. But old GHCs wouldn't accept that flag, so it doesn't make it any more convenient for people to keep their old build scripts running while squelching the warning. Or we could drop the deprecation warning for now and start bleating about it next release.
</p>
<p>
Setting priority high because whatever we decide to do, we need to decide it before 7.10 release.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9956#changelog
http://ghc.haskell.org/trac/ghc/ticket/7930
http://ghc.haskell.org/trac/ghc/ticket/7930#7930: Nested STM Invariants are lostFri, 24 May 2013 16:26:15 GMTfryguybob<p>
Invariants from a successful nested transaction should be merged with the parent.
</p>
<pre class="wiki">import Control.Concurrent
import Control.Concurrent.STM
main = do
x <- atomically $
do a <- newTVar True
(always (readTVar a) >> retry) `orElse` return ()
return a
atomically (writeTVar x False) -- Should not and does not fail
y <- atomically $
do a <- newTVar True
always (readTVar a) `orElse` return ()
return a
atomically (writeTVar y False) -- Should fail, but does not!
putStrLn "Ahhh!"
z <- atomically $
do a <- newTVar True
always (readTVar a)
return a
atomically (writeTVar z False) -- should and does fail
</pre><p>
I know how to fix this. I'll have a patch with some tests and a fix soon.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7930#changelog
http://ghc.haskell.org/trac/ghc/ticket/9686
http://ghc.haskell.org/trac/ghc/ticket/9686#9686: Link option detection does not work for incremental builds on WindowsSun, 12 Oct 2014 22:20:00 GMTgintas<p>
ghc on Linux embeds link options into the resulting binary in order to be able to tell when a binary needs to be recompiled because different link options have been passed in to ghc. This functionality is not present on Windows, forcing users to pass in -fforce-recomp.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9686#changelog
http://ghc.haskell.org/trac/ghc/ticket/7788
http://ghc.haskell.org/trac/ghc/ticket/7788#7788: Recursive type family causes <<loop>>Sat, 23 Mar 2013 04:18:09 GMTshachaf<p>
This file:
</p>
<pre class="wiki">{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}
data Proxy a = Proxy
foo :: Proxy (F (Fix Id)) -> ()
foo = undefined
newtype Fix a = Fix (a (Fix a))
newtype Id a = Id a
type family F a
type instance F (Fix a) = F (a (Fix a))
type instance F (Id a) = F a
main :: IO ()
main = print $ foo Proxy
</pre><p>
Dies with <tt><<loop>></tt>. The type family is recursive, of course:
</p>
<pre class="wiki">*Main> :kind! F (Fix Id)
F (Fix Id) :: *^CInterrupted.
</pre><p>
But <tt><<loop>></tt> is still not the behavior I'd expect. The actual value is just <tt>undefined</tt>.
</p>
<p>
In the file that this example came up, the situation was even worse -- there was a situation where
</p>
<pre class="wiki">moldMapOf l f = runAccessor . l (Accessor . f)
main = print $ (flip appEndo [] . moldMapOf (ix 3) (Endo . (:)) $ testVal :: [Int]) -- <<loop>>
main = print $ (flip appEndo [] . runAccessor . (ix 3) (Accessor . Endo . (:)) $ testVal :: [Int]) -- undefined
</pre><p>
I.e. substitution can turn one program (which happens to be ⊥ here, admittedly, but that's not fundamental) into another (<tt><<loop>></tt>). This makes it very tricky to track down the recursive type family. If necessary I can hunt down a working test case and post it here -- it's a bit tricky to get working, though.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7788#changelog
http://ghc.haskell.org/trac/ghc/ticket/8177
http://ghc.haskell.org/trac/ghc/ticket/8177#8177: Roles for type familiesTue, 27 Aug 2013 08:14:28 GMTsimonpj<p>
Now that we have <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/Roles">roles</a>, it might be helpful to be able to give a role signature for a data/type family.
</p>
<p>
At the moment, data/type family constructors have all parameters conservatively assigned to be role <tt>N</tt>. Thus
</p>
<pre class="wiki">data family D a -- Parameter conservatively assumed to be N
class C a where
op :: D a -> a
instance C Int where ....
newtype N a = MkN a deriving( C ) -- Rejected
</pre><p>
The generalised-newtype-deriving clause <tt>deriving( C )</tt> is rejected because <tt>D</tt> might use its parameter at role <tt>N</tt> thus:
</p>
<pre class="wiki">data instance D [b] = MkD (F b) -- F is a type function
</pre><p>
It would be strictly more expressive if we could
</p>
<ul><li><strong>Declare</strong> the roles of D's arguments (as we can declare their kinds). E.g.
<pre class="wiki">data family D a@R
</pre></li><li><strong>Check</strong> that each family instance obeys that role signature. E.g. given the preceding role signature, reject this instance:
<pre class="wiki">data instance D [b] = MkD (F b) -- F is a type function
</pre></li></ul><p>
I think there is no technical difficulty here. Just a question of doing it.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8177#changelog
http://ghc.haskell.org/trac/ghc/ticket/9123
http://ghc.haskell.org/trac/ghc/ticket/9123#9123: Need for higher kinded rolesMon, 19 May 2014 10:45:55 GMTsimonpj<p>
This <a class="ext-link" href="http://www.haskell.org/pipermail/ghc-devs/2014-May/004964.html"><span class="icon"></span>thread</a> on ghc-devs identifies a real shortcoming of the new roles system. Here's a compact example, from the thread
</p>
<pre class="wiki">class C m where
ret :: a -> m a
bind :: m a -> (a -> m b) -> m b
join :: m (m a) -> m a
newtype T m a = MkT (m a) deriving( C )
</pre><p>
The <tt>deriving(C)</tt> is accepted without <tt>join</tt> in the class, but rejected when <tt>join</tt> is added.
</p>
<pre class="wiki">T9123.hs:10:37:
Could not coerce from `m (m a)' to `m (T m a)'
because `m (m a)'
and `m (T m a)'
are different types.
arising from the coercion of the method `join'
from type `forall a. m (m a) -> m a'
to type `forall a. T m (T m a) -> T m a'
</pre><p>
Note that the AMP proposal adds <tt>join</tt> to class <tt>Monad</tt>!
</p>
<p>
In one way it is rightly rejected: it really would be unsound to derive an instance for <tt>C (T K)</tt> where <tt>K</tt>'s argument had nominal (but not representational) role. But we have no way to limit the type constructors at which <tt>T</tt> can be used.
</p>
<p>
This deficiency is noted in the <a class="ext-link" href="http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/"><span class="icon"></span>Safe Coercions paper</a>, but this seems to be the first occasion on which it has bitten us badly.
</p>
<p>
Edward <a class="ext-link" href="http://www.haskell.org/pipermail/ghc-devs/2014-May/004974.html"><span class="icon"></span>made a suggestion</a> on the thread.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9123#changelog
http://ghc.haskell.org/trac/ghc/ticket/9204
http://ghc.haskell.org/trac/ghc/ticket/9204#9204: Conflicting definition in hs-boot fileSat, 14 Jun 2014 08:27:20 GMTFeuerbach<p>
Foo.hs:
</p>
<pre class="wiki">module Foo where
import Bar
data Foo a
</pre><p>
Foo.hs-boot:
</p>
<pre class="wiki">module Foo where
data Foo a
</pre><p>
Bar.hs:
</p>
<pre class="wiki">module Bar where
import {-# SOURCE #-} Foo
</pre><p>
With GHC 7.8.2 I'm getting the error
</p>
<pre class="wiki">Foo.hs-boot:3:1:
Type constructor ‘Foo’ has conflicting definitions in the module
and its hs-boot file
Main module: type role Foo phantom
data Foo a
Boot file: data Foo a
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/9204#changelog
http://ghc.haskell.org/trac/ghc/ticket/9247
http://ghc.haskell.org/trac/ghc/ticket/9247#9247: Document -XDatatypeContexts in flag referenceSun, 29 Jun 2014 16:42:50 GMTgoldfire<p>
It may be a deprecated feature, but it still exists and should be listed.
</p>
<p>
I can do this.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9247#changelog
http://ghc.haskell.org/trac/ghc/ticket/9248
http://ghc.haskell.org/trac/ghc/ticket/9248#9248: Document -XHaskell98 and -XHaskell2010 in flag referenceSun, 29 Jun 2014 16:47:43 GMTgoldfireResultshttp://ghc.haskell.org/trac/ghc/ticket/9248#changelog
http://ghc.haskell.org/trac/ghc/ticket/10079
http://ghc.haskell.org/trac/ghc/ticket/10079#10079: Coercible solver regression: Couldn't match rep of () with Const () bWed, 11 Feb 2015 07:34:29 GMTglguy<p>
Hello, I ran into what appears to be a regression in the Coercible solver since 7.8.4. This is as small as I've managed to get my example case.
</p>
<pre class="wiki">{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE FlexibleContexts #-}
module Bug where
import Control.Applicative
import Data.Coerce
broken :: Bizarre (->) w => w a b t -> ()
broken = getConst #. bazaar (Const #. const ())
class Profunctor p where
(#.) :: Coercible c b => (b -> c) -> p a b -> p a c
instance Profunctor (->) where
(#.) = (.)
class Bizarre p w | w -> p where
bazaar :: Applicative f => p a (f b) -> w a b t -> f t
</pre><pre class="wiki">Bug.hs:10:36:
Couldn't match representation of type ‘()’
with that of ‘Const () b’
Relevant role signatures: type role Const representational phantom
Relevant bindings include
broken :: w a b t -> () (bound at Bug.hs:10:1)
In the first argument of ‘bazaar’, namely ‘(Const #. const ())’
In the second argument of ‘(#.)’, namely
‘bazaar (Const #. const ())’
In the expression: getConst #. bazaar (Const #. const ())
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/10079#changelog
http://ghc.haskell.org/trac/ghc/ticket/10121
http://ghc.haskell.org/trac/ghc/ticket/10121#10121: operational semantics is incomplete?Fri, 27 Feb 2015 06:09:13 GMTjavran<p>
I was trying to read <tt>docs/core-spec/core-spec.pdf</tt> to understand the operational semantics for core language. So I started off by playing with operational semantics rules manually.
</p>
<p>
But I found the following expression gets stuck:
</p>
<div class="code"><pre><span class="nf">v1</span> <span class="ow">=</span> <span class="kr">let</span> fix <span class="ow">=</span> <span class="nf">\</span>f <span class="ow">-></span> <span class="kr">let</span> x <span class="ow">=</span> f x <span class="kr">in</span> x
pf <span class="ow">=</span> <span class="nf">\</span>f x <span class="ow">-></span> <span class="kr">if</span> x <span class="o">==</span> <span class="mi">0</span>
<span class="kr">then</span> x
<span class="kr">else</span> f <span class="p">(</span>pred x<span class="p">)</span>
<span class="kr">in</span> <span class="p">(</span>fix pf<span class="p">)</span> <span class="mi">2</span>
<span class="c1">-- S_LETNONREC</span>
<span class="nf">v2</span> <span class="ow">=</span> <span class="p">((</span><span class="nf">\</span>f <span class="ow">-></span> <span class="kr">let</span> x <span class="ow">=</span> f x <span class="kr">in</span> x<span class="p">)</span>
<span class="p">(</span><span class="nf">\</span>f x <span class="ow">-></span> <span class="kr">if</span> x <span class="o">==</span> <span class="mi">0</span>
<span class="kr">then</span> x
<span class="kr">else</span> f <span class="p">(</span>pred x<span class="p">)))</span>
<span class="mi">2</span>
<span class="c1">-- S_APP</span>
<span class="nf">v3</span> <span class="ow">=</span> <span class="p">(</span><span class="kr">let</span> x <span class="ow">=</span> <span class="p">(</span><span class="nf">\</span>f x <span class="ow">-></span> <span class="kr">if</span> x <span class="o">==</span> <span class="mi">0</span>
<span class="kr">then</span> x
<span class="kr">else</span> f <span class="p">(</span>pred x<span class="p">))</span> x
<span class="kr">in</span> x<span class="p">)</span> <span class="mi">2</span>
<span class="c1">-- S_APP; S_LETREC</span>
<span class="nf">v4</span> <span class="ow">=</span> <span class="p">(</span><span class="kr">let</span> x <span class="ow">=</span> <span class="p">(</span><span class="nf">\</span>f x <span class="ow">-></span> <span class="kr">if</span> x <span class="o">==</span> <span class="mi">0</span>
<span class="kr">then</span> x
<span class="kr">else</span> f <span class="p">(</span>pred x<span class="p">))</span> x
<span class="kr">in</span> <span class="p">(</span><span class="nf">\</span>f x <span class="ow">-></span> <span class="kr">if</span> x <span class="o">==</span> <span class="mi">0</span>
<span class="kr">then</span> x
<span class="kr">else</span> f <span class="p">(</span>pred x<span class="p">))</span> x<span class="p">)</span> <span class="mi">2</span>
<span class="c1">-- S_APP</span>
<span class="nf">v5</span> <span class="ow">=</span> <span class="p">(</span><span class="kr">let</span> x <span class="ow">=</span> <span class="p">(</span><span class="nf">\</span>f x <span class="ow">-></span> <span class="kr">if</span> x <span class="o">==</span> <span class="mi">0</span>
<span class="kr">then</span> x
<span class="kr">else</span> f <span class="p">(</span>pred x<span class="p">))</span> x
<span class="kr">in</span> <span class="p">(</span><span class="nf">\</span>x1 <span class="ow">-></span> <span class="kr">if</span> x1 <span class="o">==</span> <span class="mi">0</span>
<span class="kr">then</span> x1
<span class="kr">else</span> x <span class="p">(</span>pred x1<span class="p">)))</span> <span class="mi">2</span>
</pre></div><p>
at this point <tt>x</tt> is not a free variable so <tt>S_LETRECRETURN</tt> cannot be applied.
</p>
<p>
Did I make it wrong or some rules are missing for the operational semantics?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/10121#changelog
http://ghc.haskell.org/trac/ghc/ticket/7644
http://ghc.haskell.org/trac/ghc/ticket/7644#7644: Hackage docs for base library contain broken linksThu, 31 Jan 2013 14:13:24 GMTJulesBean<p>
<a class="ext-link" href="http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/GHC-IOArray.html"><span class="icon"></span>http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/GHC-IOArray.html</a>
</p>
<p>
Is a 404, presumably because it's <tt> {-# HADDOCK_OPTIONS hide #-} </tt> so the haddocks don't get documented?
</p>
<p>
However it is linked to from the master index
</p>
<p>
<a class="ext-link" href="http://hackage.haskell.org/package/base-4.6.0.0"><span class="icon"></span>http://hackage.haskell.org/package/base-4.6.0.0</a>
</p>
<p>
...which as far as I can see has links to all modules irrespective of whether they are hidden or not.
</p>
<p>
A different example relates to source links:
</p>
<p>
If you look at the Prelude docs here:
</p>
<p>
<a class="ext-link" href="http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/Prelude.html"><span class="icon"></span>http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/Prelude.html</a>
</p>
<p>
Then some of the source links point to URLs like
</p>
<p>
<a class="ext-link" href="http://hackage.haskell.org/packages/archive/%01/%02/doc/html/src/GHC-Classes.html#Ord"><span class="icon"></span>http://hackage.haskell.org/packages/archive/%01/%02/doc/html/src/GHC-Classes.html#Ord</a>
</p>
<p>
...which looks like some substitution operation has failed (%01 -> package name, %02 -> version, I presume). An attempt to manually fix the package name and version still leads to a 404.
</p>
<p>
Some other source links from the Prelude are fine, though, for example:
</p>
<p>
<a class="ext-link" href="http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/src/GHC-Enum.html#Enum"><span class="icon"></span>http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/src/GHC-Enum.html#Enum</a>
</p>
<p>
This is a regression but I don't know how recently; I certainly used to be able to follow links like that back in the 7.0 era, but I don't when it started failing.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7644#changelog
http://ghc.haskell.org/trac/ghc/ticket/9782
http://ghc.haskell.org/trac/ghc/ticket/9782#9782: Do not by default set ekmett as owner for 'Core libraries'Fri, 07 Nov 2014 14:59:06 GMTthomie<p>
And if possible, do a mass update of removing him from existing tickets: <a class="ext-link" href="https://ghc.haskell.org/trac/ghc/query?component=Core+Libraries&owner=ekmett"><span class="icon"></span>https://ghc.haskell.org/trac/ghc/query?component=Core+Libraries&owner=ekmett</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9782#changelog
http://ghc.haskell.org/trac/ghc/ticket/10024
http://ghc.haskell.org/trac/ghc/ticket/10024#10024: This bug tracker: Can not create filter `x contains y && x contains z`Mon, 26 Jan 2015 19:58:08 GMTlspitzner<p>
To Reproduce:
</p>
<ul><li>Start ticket search
</li><li>Create filter "description" and set phrase to "foo"
</li><li>Click the button "And" again, choose "description", set phrase to "bar"
</li><li>The filter now is set to <tt>description contains foo || description contains bar</tt>, instead of the expected <tt>s/||/&&/</tt>.
</li></ul><p>
Note that setting phrase to "foo bar" seems to search for "foo bar", not <tt>fold (||) . words</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/10024#changelog
http://ghc.haskell.org/trac/ghc/ticket/10025
http://ghc.haskell.org/trac/ghc/ticket/10025#10025: Tracker: "My Tickets" does not workMon, 26 Jan 2015 20:33:57 GMTlspitzner<p>
I have non-zero set of tickets here, yet search returns empty list. No filters other than author=lspitzner.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/10025#changelog
http://ghc.haskell.org/trac/ghc/ticket/9274
http://ghc.haskell.org/trac/ghc/ticket/9274#9274: GHC panic with UnliftedFFITypes+CApiFFISun, 06 Jul 2014 11:44:10 GMThvr<p>
The following code fails to compile with at least GHC 7.6, 7.8 and HEAD:
</p>
<div class="code"><pre><span class="kr">import</span> <span class="nn">GHC.Prim</span>
<span class="kr">import</span> <span class="nn">Foreign.C</span>
<span class="kr">type</span> <span class="kt">GmpLimb</span> <span class="ow">=</span> <span class="kt">CULong</span>
<span class="kr">type</span> <span class="kt">GmpSize</span> <span class="ow">=</span> <span class="kt">CLong</span>
<span class="c1">-- mp_limb_t mpn_add_1 (mp_limb_t *rp, const mp_limb_t *s1p, mp_size_t n, mp_limb_t s2limb)</span>
<span class="nf">foreign</span> <span class="kr">import</span> <span class="nn">capi</span> unsafe <span class="s">"gmp.h mpn_add_1"</span>
c_mpn_add_1 <span class="ow">::</span> <span class="kt">MutableByteArray</span><span class="o">#</span> s <span class="ow">-></span> <span class="kt">ByteArray</span><span class="o">#</span> <span class="ow">-></span> <span class="kt">GmpSize</span> <span class="ow">-></span> <span class="kt">GmpLimb</span> <span class="ow">-></span> <span class="kt">IO</span> <span class="kt">GmpLimb</span>
</pre></div><p>
with the following compile error message:
</p>
<pre class="wiki">ghc: panic! (the 'impossible' happened)
(GHC version 7.9.20140704 for x86_64-unknown-linux):
toCType MutableByteArray# s
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre><p>
Otoh, replacing <tt>capi</tt> with <tt>ccall</tt> makes the code compile just fine
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9274#changelog
http://ghc.haskell.org/trac/ghc/ticket/8173
http://ghc.haskell.org/trac/ghc/ticket/8173#8173: GHC uses nubMon, 26 Aug 2013 12:12:55 GMTnh2<p>
nub is O(n²).
</p>
<p>
I bet all usages have Ord instances.
</p>
<p>
<a class="ext-link" href="https://github.com/nh2/haskell-ordnub"><span class="icon"></span>https://github.com/nh2/haskell-ordnub</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8173#changelog
http://ghc.haskell.org/trac/ghc/ticket/9525
http://ghc.haskell.org/trac/ghc/ticket/9525#9525: +RTS -xc stack trace sometimes reported twiceSat, 30 Aug 2014 10:57:18 GMTosa1<p>
Not sure if really a bug but just wanted to show. If this is a bug I'm hoping to fix this myself but I may need some guidance.
</p>
<p>
Stack trace reported by <tt>+RTS -xc</tt> is sometimes printed twice. This program reports it only once, as expected:
</p>
<div class="code"><pre><span class="nf">f</span> <span class="ow">::</span> <span class="kt">Int</span> <span class="ow">-></span> <span class="kt">Int</span>
<span class="nf">f</span> <span class="ow">=</span> <span class="ne">error</span> <span class="s">"hello"</span>
<span class="nf">main</span> <span class="ow">=</span> print <span class="p">(</span>f <span class="mi">20</span><span class="p">)</span>
</pre></div><pre class="wiki">➜ ghc_patch ./error +RTS -xc
*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
Main.f,
called from Main.CAF
--> evaluated by: Main.main,
called from Main.CAF
error: hello
</pre><p>
But if I change it to this:
</p>
<div class="code"><pre><span class="nf">f</span> <span class="ow">::</span> <span class="kt">Int</span> <span class="ow">-></span> <span class="kt">Int</span>
<span class="nf">f</span> x <span class="ow">=</span>
<span class="kr">let</span> x <span class="ow">=</span> x <span class="o">+</span> <span class="mi">20</span>
<span class="kr">in</span> x
<span class="nf">main</span> <span class="ow">=</span> print <span class="p">(</span>f <span class="mi">20</span><span class="p">)</span>
</pre></div><p>
Stack trace is reported twice:
</p>
<pre class="wiki">➜ ghc_patch ./error +RTS -xc
*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Main.f.x,
called from Main.f,
called from Main.main,
called from Main.CAF
*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Main.f.x,
called from Main.f,
called from Main.main,
called from Main.CAF
error: <<loop>>
</pre><p>
Can anyone confirm that this is really a bug?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9525#changelog
http://ghc.haskell.org/trac/ghc/ticket/7307
http://ghc.haskell.org/trac/ghc/ticket/7307#7307: Share top-level code for stringsMon, 08 Oct 2012 13:16:26 GMTsimonpj<p>
A string constant in GHC turns into
</p>
<pre class="wiki">foo :: String
foo = unpackCString# "the-string'
</pre><p>
This is a top-level thunk, and it expands into rather a lot of code like this
</p>
<pre class="wiki">.text
.align 4,0x90
.long 0
.long 22
.globl _Foo_zdfTypeableTzuds1_info
_Foo_zdfTypeableTzuds1_info:
.LcvI:
movl %esi,%eax
leal -12(%ebp),%ecx
cmpl 84(%ebx),%ecx
jb .LcvQ
addl $8,%edi
cmpl 92(%ebx),%edi
ja .LcvS
movl $_stg_CAF_BLACKHOLE_info,-4(%edi)
movl 100(%ebx),%ecx
movl %ecx,0(%edi)
leal -4(%edi),%ecx
pushl %ecx
pushl %eax
pushl %ebx
movl %eax,76(%esp)
call _newCAF
addl $12,%esp
testl %eax,%eax
je .LcvL
movl $_stg_bh_upd_frame_info,-8(%ebp)
leal -4(%edi),%eax
movl %eax,-4(%ebp)
movl $_cvJ_str,-12(%ebp)
addl $-12,%ebp
jmp _ghczmprim_GHCziCString_unpackCStringzh_info
.LcvL:
movl 64(%esp),%eax
jmp *(%eax)
.LcvS:
movl $8,116(%ebx)
.LcvQ:
movl %eax,%esi
jmp *-12(%ebx)
</pre><p>
That's rather a lot of goop for one thunk! Of course we can share this, by making a 2-word thunk like this:
</p>
<pre class="wiki">------------------------------
| TopUnpack_info | -------|-----> "the-string"#
------------------------------
</pre><p>
where <tt>TopUnpack_info</tt> is a shared RTS info-table and code that embodies the code fragment above.
</p>
<p>
This would save useless code bloat for every constant string. (This came up when looking at the code generated by <tt>deriving(Typeable)</tt>.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7307#changelog
http://ghc.haskell.org/trac/ghc/ticket/8198
http://ghc.haskell.org/trac/ghc/ticket/8198#8198: One-shot mode is buggy w.r.t. hs-boot filesFri, 30 Aug 2013 00:46:39 GMTparcs<p>
Consider
</p>
<h3 id="A.hs-boot">A.hs-boot</h3>
<div class="code"><pre><span class="kr">module</span> <span class="nn">A</span> <span class="kr">where</span>
</pre></div><h3 id="B.hs">B.hs</h3>
<div class="code"><pre><span class="kr">module</span> <span class="nn">B</span> <span class="kr">where</span>
<span class="kr">import</span> <span class="err">{-#</span> <span class="nn">SOURCE</span> <span class="o">#-</span><span class="p">}</span> <span class="kt">A</span>
</pre></div><h3 id="CommandLine">Command Line</h3>
<pre class="wiki">$ ghc -c A.hs-boot B.hs
B.hs:3:1:
Bad interface file: A.hi-boot-boot
A.hi-boot-boot: openBinaryFile: does not exist (No such file or directory)
</pre><p>
I expect the modules to get compiled cleanly. Instead I get an error.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8198#changelog