GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=infoneeded&status=merge&status=new&status=patch&component=Compiler&milestone=7.6.2&group=status&order=priority
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?status=infoneeded&status=merge&status=new&status=patch&component=Compiler&milestone=7.6.2&group=status&order=priority
Trac 1.0.1
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/5539
http://ghc.haskell.org/trac/ghc/ticket/5539#5539: GHC panic - Simplifier ticks exhaustedSat, 08 Oct 2011 22:05:07 GMThvr<p>
When trying to install <tt>blaze-builder</tt> with a freshly installed GHC 7.3.20111007 linux/amd64 build, the following panic occurs:
</p>
<pre class="wiki">$ cabal install blaze-builder
Resolving dependencies...
Configuring blaze-builder-0.3.0.1...
Building blaze-builder-0.3.0.1...
Preprocessing library blaze-builder-0.3.0.1...
...
[10 of 13] Compiling Blaze.ByteString.Builder.HTTP ( Blaze/ByteString/Builder/HTTP.hs, dist/build/Blaze/ByteString/Builder/HTTP.o )
[11 of 13] Compiling Blaze.ByteString.Builder.Int ( Blaze/ByteString/Builder/Int.hs, dist/build/Blaze/ByteString/Builder/Int.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.3.20111007 for x86_64-unknown-linux):
Simplifier ticks exhausted
When trying UnfoldingDone a_s9oE{v} [lid]
To increase the limit, use -fsimpl-tick-factor=N (default 100)
If you need to do this, let GHC HQ know, and what factor you needed
To see detailed counts use -ddump-simpl-stats
Total ticks: 5123
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5539#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/5763
http://ghc.haskell.org/trac/ghc/ticket/5763#5763: Confusing error messageWed, 11 Jan 2012 08:26:59 GMTsimonpj<p>
For test <tt>indexed-types/should_fail/T4272</tt> we get this type error
</p>
<pre class="wiki">T4272.hs:11:16:
Occurs check: cannot construct the infinite type:
x0 = TermFamily x0 x0
Expected type: TermFamily x0 x0
Actual type: TermFamily a a
In the first argument of `prune', namely `t'
In the expression: prune t (terms (undefined :: TermFamily a a))
In an equation for `laws':
laws t = prune t (terms (undefined :: TermFamily a a))
</pre><p>
It's not at all obvious why unifying <tt>(TermFamily x0 x0)</tt> with <tt>(TermFamily a a)</tt> should yield an occurs check. Especially as <tt>TermFamily</tt> is a type function with arity 1, and <tt>x0</tt> is a unification variable. So the natural way to solve this constraint would be to unify <tt>x0</tt> with <tt>a</tt>, and then the constraint is satisfied.
</p>
<p>
What goes wrong is that there is <em>another</em> insolube constraint (which is also reported):
</p>
<pre class="wiki">T4272.hs:11:19:
Could not deduce (a ~ TermFamily x0 x0)
from the context (TermLike a)
bound by the type signature for
laws :: TermLike a => TermFamily a a -> b
at T4272.hs:11:1-54
`a' is a rigid type variable bound by
the type signature for laws :: TermLike a => TermFamily a a -> b
at T4272.hs:11:1
In the return type of a call of `terms'
In the second argument of `prune', namely
`(terms (undefined :: TermFamily a a))'
In the expression: prune t (terms (undefined :: TermFamily a a))
</pre><p>
The constraint solver finds this latter constraint, can't solve it, <em>but still uses it to simplify the first one</em>, by substituting <tt>(TermFamily x0 x0)</tt> for <tt>a</tt>; and that is what gives the occurs check error.
</p>
<p>
I don't think that we should use <em>insoluble</em> constraints to rewrite unsolved constraints. But it's delicate, so I am not trying to fiddle right now. Hence making this ticket.
</p>
<p>
(Incidentally, it's not a regression; it's been like this forever.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5763#changelog
http://ghc.haskell.org/trac/ghc/ticket/5954
http://ghc.haskell.org/trac/ghc/ticket/5954#5954: Performance regression 7.0 -> 7.2 (still in 7.4)Tue, 20 Mar 2012 11:51:11 GMTsimonmar<p>
The program in <tt>nofib/parallel/blackscholes</tt> regressed quite badly in performance between 7.0.x and 7.2.1. This is just sequential performance, no parallelism.
</p>
<p>
With 7.0:
</p>
<pre class="wiki"> 3,084,786,008 bytes allocated in the heap
5,150,592 bytes copied during GC
33,741,048 bytes maximum residency (7 sample(s))
1,541,904 bytes maximum slop
64 MB total memory in use (2 MB lost due to fragmentation)
Generation 0: 5760 collections, 0 parallel, 0.08s, 0.08s elapsed
Generation 1: 7 collections, 0 parallel, 0.01s, 0.01s elapsed
INIT time 0.00s ( 0.00s elapsed)
MUT time 17.43s ( 17.47s elapsed)
GC time 0.09s ( 0.09s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 17.53s ( 17.56s elapsed)
</pre><p>
With 7.2.2:
</p>
<pre class="wiki"> 3,062,127,752 bytes allocated in the heap
4,714,784 bytes copied during GC
34,370,232 bytes maximum residency (7 sample(s))
1,553,968 bytes maximum slop
64 MB total memory in use (2 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 5781 colls, 0 par 0.08s 0.08s 0.0000s 0.0006s
Gen 1 7 colls, 0 par 0.01s 0.01s 0.0014s 0.0017s
INIT time 0.00s ( 0.00s elapsed)
MUT time 23.93s ( 23.93s elapsed)
GC time 0.09s ( 0.09s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 24.02s ( 24.03s elapsed)
</pre><p>
and with 7.4.1:
</p>
<pre class="wiki"> 3,061,924,144 bytes allocated in the heap
4,733,760 bytes copied during GC
34,210,896 bytes maximum residency (7 sample(s))
1,552,640 bytes maximum slop
64 MB total memory in use (2 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 5781 colls, 0 par 0.08s 0.08s 0.0000s 0.0007s
Gen 1 7 colls, 0 par 0.01s 0.01s 0.0015s 0.0017s
INIT time 0.00s ( 0.00s elapsed)
MUT time 23.90s ( 23.91s elapsed)
GC time 0.09s ( 0.09s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 24.00s ( 24.00s elapsed)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5954#changelog
http://ghc.haskell.org/trac/ghc/ticket/6166
http://ghc.haskell.org/trac/ghc/ticket/6166#6166: Performance regression in mwc-random since 7.0.xFri, 15 Jun 2012 23:25:16 GMTbos<p>
I've had a report that the performance of the mwc-random package has regressed seriously after upgrading from GHC 7.0 to 7.4. It turns out that 7.2 also has the regression.
</p>
<p>
Here's a sample program.
</p>
<pre class="wiki">import qualified Data.Vector.Unboxed as U
import qualified System.Random.MWC as R
import System.Random.MWC.Distributions (standard)
count = 1000 * 1000
fast gen = standard gen
slow gen = standard gen >>= return
-- Edit this to choose fast or slow.
which gen = slow gen
main = do
gen <- R.create
v <- U.replicateM count (which gen)
print (U.last v)
</pre><p>
With GHC 7.0.3 -O2, this runs in 0.294 sec, regardless of whether <tt>fast</tt> or <tt>slow</tt> is used.
</p>
<p>
Under 7.4, <tt>fast</tt> runs in 0.062 sec (a nice speedup!), but <tt>slow</tt> now takes 9.2 sec (yikes!).
</p>
<p>
Roman suggested compiling the <tt>slow</tt> version with <tt>-fno-state-hack</tt>, which brings performance back up to 0.062 sec.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/6166#changelog
http://ghc.haskell.org/trac/ghc/ticket/849
http://ghc.haskell.org/trac/ghc/ticket/849#849: Offer control over branch predictionTue, 08 Aug 2006 14:23:41 GMTsimonpj<p>
So now that GHC is so good at producing really fast low level code (see
ByteString benchmarks) we start to encounter low level gubbins where to
get the fastest possible code we need slightly more influence over
branch prediction.
</p>
<p>
In the code for ByteString's 'writeStrUp/Dn' functions we're doing a
tight loop writing bytes to memory.
</p>
<p>
The first version looks much like this:
</p>
<pre class="wiki">loop fp n off s = case next s of
Done -> return $! PS fp 0 off
Skip s' -> loop fp n off s'
Yield x s' -> do
withForeignPtr fp $ \p -> pokeByteOff p off x
loop fp n (off+1) s'
</pre><p>
When we get to the end of a memory block we need to double the size of
the memory block and carry on. So this adds an additional conditional
test into this loop.
</p>
<pre class="wiki">loop fp n off s = case next s of
Done -> trimUp fp n off
Skip s' -> loop fp n off s'
Yield x s'
| n == off -> realloc fp n off s' x
| otherwise -> do
withForeignPtr fp $ \p -> pokeByteOff p off x
loop fp n (off+1) s'
</pre><p>
There are dramatic differences between equivalent forms of code. Just by
reversing the order of the (n==off) test one form I can process 50Mb of
data in 0.20 seconds and in the other it takes 0.34 seconds.
</p>
<p>
That is:
</p>
<pre class="wiki"> | n == off -> realloc fp n off s' x
| otherwise -> do ...
</pre><p>
vs
</p>
<pre class="wiki"> | n /= off -> do ...
| otherwise -> realloc fp n off s' x
</pre><p>
I think that this is all down to branch prediction and the arrangement
of basic blocks. On a modern CPU correctly predicted branches are nearly
free while mis-predicted branches are very costly due to stalled
pipelines etc.
</p>
<p>
In gcc they have a branch prediction framework. It annotates
conditionals with prediction information. It then uses that during code
generation to do things like arranging basic blocks so that unlikely
blocks are moved out of line. It gets the prediction information from a
few sources. One is a simple static branch predictor, for example
branches back to to the beginning of a loop are likely to be taken and
branches to error functions are not. gcc even has a profile feedback
system to find the real probabilities of branches from a sample run of
the program. It also has a user annotation <tt>__builtin_expect()</tt> which many
C projects use in the form of a macro:
</p>
<pre class="wiki">if (unlikely(x==0)) { ...
</pre><p>
The Linux kernel uses this fairly heavily to move error handling code
out of the main 'fast path' code.
</p>
<p>
Anyway, so what I wish is that I could write something like:
</p>
<pre class="wiki">loop fp n off s = case next s of
Done -> {-# UNLIKELY #-}
trimUp fp n off
Skip s' -> loop fp n off s'
Yield x s'
| n == off -> {-# UNLIKELY #-}
realloc fp n off s' x
| otherwise -> do
withForeignPtr fp $ \p -> pokeByteOff p off x
loop fp n (off+1) s'
</pre><p>
The best approximating effect that I can use at the moment is to make
the unlikely realloc branch a local function in a where clause but mark
it with <tt> {-# NOINLINE #-} </tt> so that the code for the realloc case doesn't
pollute the tight loop for the normal fast case. Then the other
approximation is fiddling with the logic of the binary test and looking
at the benchmarks. The combination of these two techniques makes a
dramatic difference to the speed.
</p>
<p>
However I do need more control to do it reliably, while I was able to
make it work for writeStrUp, I could not find a combination to work for
writeStrDn - we loose about 50% performance when we add the realloc
branch. So a slightly more reliable method to hint at the likelihood of
conditionals would make this kind of low level code faster and easier to
write.
</p>
<p>
Some time ago as a quick hack I did add a branch prediction annotation
to the CMM conditional constructor. I only used it in the C backend to
turn it into uses of gcc's <tt>__builtin_expect()</tt>. I also didn't connect it
to the front end so I didn't have any high level static branch
prediction (which could be done by looking for branches with recursive
calls or calls to error etc). The only place I did actually use it was
in the heap check and stack check. I assumed that it would be
advantageous to predict heap and stack overflow branches as not taken.
It was only a quick hack - I didn't do any benchmarks to see if it had
any effect.
</p>
<p>
Anyway, just a thought, and of course not something we should be
thinking about 'til post 6.6.
</p>
<p>
Duncan
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/849#changelog
http://ghc.haskell.org/trac/ghc/ticket/888
http://ghc.haskell.org/trac/ghc/ticket/888#888: Implement the static argument transformationMon, 04 Sep 2006 16:37:57 GMTsimonpj<p>
The Static Argument transformation optimises
</p>
<pre class="wiki"> f x y = ....f x' y...
</pre><p>
into
</p>
<pre class="wiki"> f x y = let g x = ....g x'...
in g x
</pre><p>
Instead of passing <tt>y</tt> along unchanged, we make it into a free variable of a local function definition <tt>g</tt>.
</p>
<p>
Unfortunately, it's not always a win. Andre Santos gives a discussion, and quite a few numbers in <a class="ext-link" href="http://research.microsoft.com/%7Esimonpj/Papers/santos-thesis.ps.gz"><span class="icon"></span>his thesis</a>.
</p>
<p>
But sometimes it is a pretty big win. Here's the example that recently motivated me, which Roman Leshchinskiy showed me. You need the attached file Stream.hs, and then try compiling
</p>
<pre class="wiki"> import Stream
foo :: (a -> b) -> [a] -> [c]
foo f = mapL f
</pre><p>
Thus inspired, I think I have a set of criteria that would make the static arg transformation into a guaranteed win:
</p>
<ul><li>there is only one (external) call to the function
</li><li>OR its RHS is small enough to inline
</li><li>OR it is marked INLINE (?)
</li></ul><p>
So I'd like to try this idea out.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/888#changelog
http://ghc.haskell.org/trac/ghc/ticket/1216
http://ghc.haskell.org/trac/ghc/ticket/1216#1216: Missed opportunity for let-no-esapeMon, 12 Mar 2007 16:57:04 GMTclaus<p>
readArray/writeArray call GHC.Arr.index, which seems inexplicably slow
for 2d arrays. inexplicably, because simply copying the default implementation
of index from GHC.Arr into the local module can speed things up considerably.
</p>
<p>
originally raised in this thread:
<a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2007-March/023394.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2007-March/023394.html</a>
</p>
<p>
shortened example or matrix/vector-multiplication attached. comment out
the first line of myindex to use the local copy. this results in a speedup
from 20s to 13s (time ./Index 100000) on my system, not to mention the
difference in space usage (a factor of 1000 in allocation, according to
+RTS -sstderr..).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1216#changelog
http://ghc.haskell.org/trac/ghc/ticket/1349
http://ghc.haskell.org/trac/ghc/ticket/1349#1349: Generalise the ! and UNPACK mechanism for data types, to unpack function argumentsFri, 11 May 2007 12:51:40 GMTsimonpj<p>
See this thread:
</p>
<blockquote>
<p>
<a class="ext-link" href="http://www.nabble.com/More-speed-please!-t3411977.html"><span class="icon"></span>http://www.nabble.com/More-speed-please!-t3411977.html</a>
</p>
</blockquote>
<p>
Briefly the idea is to allow
</p>
<pre class="wiki"> data T = MkT (!Int -> Bool)
</pre><p>
to make a <tt>MkT</tt> hold strict functions only. Anyone unpacking a <tt>MkT</tt> can assume the function is strict; and anyone building a <tt>MkT</tt> gets a strictness wrapper aound whatever function they supply, so even if they supply a lazy function, it's made strict.
</p>
<p>
Seems like a natural generalisation of the existing strictness and UNPACK mechanism for data types.
</p>
<p>
Lots of details in the thread above.
</p>
<p>
Simon
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1349#changelog
http://ghc.haskell.org/trac/ghc/ticket/1466
http://ghc.haskell.org/trac/ghc/ticket/1466#1466: Stack check for AP_STACKThu, 28 Jun 2007 09:43:51 GMTsimonmar<p>
This is a bug I uncovered in the interpreter, that I think is also present in the compiler.
</p>
<p>
When compiling code for a function or thunk, we aggregate the stack usage from case continuations up to the top of the function/thunk and perform a single stack check. This normally works fine: we know the maximum amount of stack that will be required in the evaluation of this function/thunk, and we check for it up front.
</p>
<p>
However, this goes wrong if the evaluation is suspended by an asynchronous exception: the stack is broken into chunks and stored in <tt>AP_STACK</tt> objects, which may later be resumed. On resumption, we might not have enough stack any more: the code might now be running on another stack entirely, even.
</p>
<p>
Our proposed solution is as follows:
</p>
<ul><li>Continuations that require more than a certain amount of stack (say 4k)
do their own stack checks.
</li></ul><ul><li>an AP_STACK object records the amount of stack available at the time it
was suspended, if the amount is <4k. On resumption of an AP_STACK, we
ensure that at least this amount of stack is available. (there's a
spare half-word field in AP_STACK that we can use for this).
</li></ul><p>
The 4k limit is important: it puts a bound on the amount of stack growth due to evaluating an AP_STACK. Essentially the 4k limit is large enough that it almost never happens.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1466#changelog
http://ghc.haskell.org/trac/ghc/ticket/1544
http://ghc.haskell.org/trac/ghc/ticket/1544#1544: Derived Read instances for recursive datatypes with infix constructors are too inefficientWed, 18 Jul 2007 05:24:51 GMTjcpetruzza@…<p>
Consider this definition:
</p>
<pre class="wiki">data Exp = C | Exp :+: Exp | Exp :-: Exp deriving ( Read, Show )
</pre><p>
Now, try something like:
</p>
<pre class="wiki">> read "((((((((((C))))))))))" :: Exp
</pre><p>
Even this simple expression may take several seconds to parse. It gets worse if you keep adding parenthesis. And even worse if you add more infix constructors....
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1544#changelog
http://ghc.haskell.org/trac/ghc/ticket/1965
http://ghc.haskell.org/trac/ghc/ticket/1965#1965: Allow unconstrained existential contexts in newtypesSat, 08 Dec 2007 21:02:05 GMTguest<p>
Declarations like
</p>
<pre class="wiki">newtype Bar = forall a. Bar (Foo a)
</pre><p>
ought to be allowed so long as no typeclass constraints are added. Right now, this requires data rather than newtype.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1965#changelog
http://ghc.haskell.org/trac/ghc/ticket/3085
http://ghc.haskell.org/trac/ghc/ticket/3085#3085: warn about language extensions that are not usedWed, 11 Mar 2009 18:03:32 GMTPVerswyvelen<p>
When I put
</p>
<p>
<tt>{-# OPTIONS_GHC -Wall -Werror #-}</tt>
</p>
<p>
in my source file, I don't get compiler warnings about redundant language extensions that I enabled in that file.
</p>
<p>
For example if I write
</p>
<p>
<tt>{-# LANGUAGE GeneralizedNewtypeDeriving #-}</tt>
</p>
<p>
in the file, but I never do newtype deriving, the compiler could give me a warning.
</p>
<p>
It would be nice if the compiler gave warnings about this, since after refactoring, some language extensions might not be needed anymore, and hence should be removed since fewer language extensions mean more stable and portable code no?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3085#changelog
http://ghc.haskell.org/trac/ghc/ticket/3217
http://ghc.haskell.org/trac/ghc/ticket/3217#3217: Make GHCi have separate flags for interactive Haskell expressionsMon, 11 May 2009 12:17:58 GMTsimonpj<p>
It's becoming clear that in GHCi we want to have a separate set of command-line flags for
</p>
<ul><li>Compiling Haskell expressions typed at the GHCi prompt
</li><li>Compiling entire modules, eg via <tt>:load</tt>
</li></ul><p>
Examples of this need are:
</p>
<ul><li>We already have an ad-hoc difference in the way that type-class defaults are applied: <a href="http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html#extended-default-rules">http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html#extended-default-rules</a>
</li><li>In <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3202" title="feature request: Make XNoMonomorphismRestriction the default in GHCi (closed: fixed)">#3202</a> there's a well-argued request to change behaviour of the monomorphism restriction
</li></ul><p>
So the new feature would consist of:
</p>
<ul><li>The <tt>InteractiveContext</tt> should contain a set of <tt>DynFlags</tt> used for compiling command-line Haskell expressions (the <em>interactive <tt>DynFlags</tt></em>)
</li><li>The <tt>:set</tt> command would change both the <tt>DynFlags</tt> maintained by GHCi for compiling entire modules (the <em>batch <tt>DynFlags</tt></em>), and the interactive <tt>DynFlags</tt>.
</li><li>A new <tt>:seti</tt> command to change the interactive flags
</li><li>Just possibly a <tt>:setb</tt> command to set the batch flags but leave the interactive ones unchanged.
</li></ul><p>
Arguably it'd be good to have a command to display the current flag settings (of either <tt>DynFlags</tt>) but that's another blob of work.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3217#changelog
http://ghc.haskell.org/trac/ghc/ticket/3379
http://ghc.haskell.org/trac/ghc/ticket/3379#3379: GHC should use the standard binary packageFri, 17 Jul 2009 23:11:12 GMTigloo<p>
GHC should use the standard binary package, rather than reimplementing its functionality itself. If the current binary package is slower than GHC's Binary, then we should fix that.
</p>
<p>
There's some discussion about this in <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3041" title="feature request: Arch independent binary representations (closed: fixed)">#3041</a>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3379#changelog
http://ghc.haskell.org/trac/ghc/ticket/4092
http://ghc.haskell.org/trac/ghc/ticket/4092#4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64#Mon, 24 May 2010 15:57:54 GMTmalosh<p>
There are currently two ways to compute the ulp of double numbers with GHC :
</p>
<ul><li>Calling a C function, which requires to allocate a pointer. This is way too expensive when using interval arithmetic (for instance), that compute two ULPs at each arithmetic operations.
</li><li>Programming it by hand in haskell with GHC primitive operations, which requires using unsafeCoerce# : this does not work in GHC 6.12.2.
</li></ul><p>
unsafeCoerce# should work, and there should be a primitive ulp# function in GHC, operating on Doubles at least.
By the way, here is my haskell code using C for computing it :
</p>
<pre class="wiki">foreign import ccall unsafe "math.h frexp" c_frexp::CDouble->(Ptr CInt)->IO ()
foreign import ccall unsafe "math.h ldexp" c_ldexp::CDouble->CInt->IO CDouble
ulp::Double->Double
ulp x=unsafePerformIO $ do
expon<-alloca (\e->do
c_frexp (realToFrac x) e
peek e)
(c_ldexp 0.5 $ expon-52) >>= return.realToFrac
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4092#changelog
http://ghc.haskell.org/trac/ghc/ticket/4295
http://ghc.haskell.org/trac/ghc/ticket/4295#4295: Review higher-rank and impredicative typesTue, 07 Sep 2010 11:39:42 GMTsimonpj<p>
The ticket is a placeholder to remind me to work through the test cases for impredicative and higher rank types in the new typechecker. For now, I'm marking many of them as <tt>expect_broken</tt> on this ticket, although I think many of them really should fail.
</p>
<ul><li>tc150
</li><li>tc194
</li><li>tcfail198
</li><li>tcfail174
</li><li>tcfail165
</li><li>tcfail145
</li><li>tcfail104
</li><li>tc211
</li><li>indexed-types/should_compile/T4120
</li><li>simpl017
</li><li>Many tests in <tt>boxy/</tt> (see also <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1330" title="bug: Impredicativity bug: Church2 test gives a rather confusing error with the ... (new)">#1330</a> for Church2)
</li><li><a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/2193" title="bug: Monomorphic Pattern Bindings and Error Messages (closed: fixed)">#2193</a>
</li><li><a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/2846" title="bug: Impredicativity bug: GHC crash by type signature (closed: fixed)">#2846</a>
</li><li><a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4347" title="bug: Bug in unification of polymorphic and not-yet-polymorphic type (new)">#4347</a>
</li><li><a class="ext-link" href="http://augustss.blogspot.com/2011/07/impredicative-polymorphism-use-case-in.html"><span class="icon"></span>Lennart's blog post</a> has an interesting use case of impredicative polymorphism; it worked in 7.0, but alas not in the new typechecker.
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4295#changelog
http://ghc.haskell.org/trac/ghc/ticket/4451
http://ghc.haskell.org/trac/ghc/ticket/4451#4451: Re-linking avoidance is too aggressiveFri, 29 Oct 2010 11:33:19 GMTsimonmar<p>
I'm constantly annoyed by having to <tt>rm</tt> the binary when I want to relink with different options (<tt>-rtsopts</tt>, <tt>-threaded</tt>, etc.). We only check the date of the binary against the date of the object files and relink if it is out of date, we should really check whether the options have changed or not too.
</p>
<p>
Similar problems exist in ordinary <tt>.hs</tt> recompilation (see <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/437" title="bug: Recompilation check should include flags (closed: fixed)">#437</a>), but the solutions will be different, so it makes sense to have a separate ticket.
</p>
<p>
One solution is to store information about what settings were in effect when linking in the binary, perhaps in a special section that isn't loaded during execution. We already compile a C file during linking to support <tt>-rtsopts</tt>, so we could add some magic asm to it, and then use <tt>objdump</tt> during linking to extract the information from the existing binary if there is one.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4451#changelog
http://ghc.haskell.org/trac/ghc/ticket/4470
http://ghc.haskell.org/trac/ghc/ticket/4470#4470: Loop optimization: identical countersThu, 04 Nov 2010 10:25:50 GMTchoenerzs<p>
Consider the small program below, where 'f' has to counters 'i' and 'j'. Both are completely identical; the only difference is that 'i' is used to change 's', while 'j' changes 'm'. It would be beneficial to have GHC transform 'f' into something like 'ff' so that one register less is required.
</p>
<p>
Neither GHC nor LLVM perform this optimization.
</p>
<p>
Code of this kind occurs when one uses the "vector library". See this discussion: <a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-users/2010-November/019446.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-users/2010-November/019446.html</a>
</p>
<pre class="wiki">{-# LANGUAGE BangPatterns #-}
module Main where
import Criterion.Main
f :: Int -> Int -> Int -> Int -> Int
f !i !j !s !m
| i == 0 = s+m
| otherwise = f (i-1) (j-1) (s + i+1) (m + j*5)
g :: Int -> Int
g !k = f k k 0 0
ff :: Int -> Int -> Int -> Int
ff !i !s !m
| i == 0 = s+m
| otherwise = ff (i-1) (s + i+1) (m + i*5)
gg :: Int -> Int
gg !k = ff k 0 0
{-
main = do
print $ g 20
print $ gg 20
-}
main = defaultMain
[ bench " g" $ whnf g 20 -- 67.9ns
, bench "gg" $ whnf gg 20 -- 64.5ns
]
</pre><p>
Function 'f' produces this core:
</p>
<pre class="wiki">$wf =
\ (ww_s1uU :: Int#)
(ww1_s1uY :: Int#)
(ww2_s1v2 :: Int#)
(ww3_s1v6 :: Int#) ->
case ww_s1uU of wild_B1 {
__DEFAULT ->
$wf
(-# wild_B1 1)
(-# ww1_s1uY 1)
(+# (+# ww2_s1v2 wild_B1) 1)
(+# ww3_s1v6 (*# ww1_s1uY 5));
0 -> +# ww2_s1v2 ww3_s1v6
}
</pre><p>
'wild_B1' and 'ww1_s1uY' should be merged in this case.
</p>
<p>
The attached source is above program.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4470#changelog
http://ghc.haskell.org/trac/ghc/ticket/4937
http://ghc.haskell.org/trac/ghc/ticket/4937#4937: Remove indirections caused by sum types, such as MaybeMon, 31 Jan 2011 22:27:58 GMTtibbe<p>
While null pointers cause correctness issues in languages that allow them, they do have one benefit over <tt>Maybe</tt> when used to represent nullable values: they allow encoding the absence of a value cheaply. Using <tt>Maybe</tt> to represent a nullable value adds an extra indirection (pointer) to get to the wrapped value.
</p>
<p>
We could use the bits set by pointer tagging to encode that the pointer points directly to the value, rather than to an intermediate constructor. I believe JHC takes this approach.
</p>
<p>
A motivating example is this implementation of a hash array mapped trie (HAMT): A HAMT stores key/value pairs and subtrees in two arrays.
</p>
<pre class="wiki">data Node k v = MkNode (Array (Maybe k)) (Array (Either v (Node k v))
</pre><p>
Iff index <tt>i</tt> in the first array is <tt>Nothing</tt>, the second array contains a Node at index <tt>i</tt>, otherwise it contains a value.
</p>
<p>
Adding an extra indirection, using <tt>Maybe</tt> or <tt>Either</tt>, adds both space (in terms of extra points and data constructor headers) and time (in terms of additional cache misses and branches).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4937#changelog
http://ghc.haskell.org/trac/ghc/ticket/5075
http://ghc.haskell.org/trac/ghc/ticket/5075#5075: CPR optimisation for sum types if only one constructor is usedFri, 01 Apr 2011 21:03:24 GMTbatterseapower<p>
Inspired by <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3138" title="bug: Returning a known constructor: GHC generates terrible code for cmonad (new)">#3138</a>, it might be useful for StrAnal to detect functions such as the following where only one of the data constructors for a sum type are CPRed:
</p>
<pre class="wiki">loop x = case x < 10 of True -> Left x; False -> loop (x*2)
</pre><p>
We can usefully transform to:
</p>
<pre class="wiki">$wloop x = case (case x < 10 of True -> Left x; False -> loop (x*2)) of Left y -> (# y #)
loop x = case loop x of (# y #) -> Left y
</pre><p>
Attached patch implements this behaviour. Most of the complication in the new code occurs because adding a DataCon field to the Demand data type means that we have to define a separate IfaceDemand type for storage in interface files.
</p>
<p>
The patch validates but I haven't done any tests on nofib. I have confirmed that the new optimisation hits on some examples, though.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5075#changelog
http://ghc.haskell.org/trac/ghc/ticket/5320
http://ghc.haskell.org/trac/ghc/ticket/5320#5320: check_overlap panic (7.1 regression)Wed, 13 Jul 2011 13:19:00 GMTmikhail.vorozhtsov<p>
The attached program is rightfully rejected by GHC 7.0.4 (with <tt>"Could not deduce (HMapClass f l) ..."</tt>) but makes GHC HEAD panic:
</p>
<pre class="wiki">$ ghc-7.3.20110713 Overlap.hs
[1 of 1] Compiling Overlap ( Overlap.hs, Overlap.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.3.20110713 for x86_64-unknown-linux):
check_overlap
main:Overlap.HDropClass{tc raS}
main:Overlap.PZero{tc raZ}
(main:Overlap.HMap{tc raN} f{tv adi} [sk] l{tv adk} [sk])
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre><p>
Both versions are built with the devel2 BuildFlavour.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5320#changelog
http://ghc.haskell.org/trac/ghc/ticket/5355
http://ghc.haskell.org/trac/ghc/ticket/5355#5355: Link plugins against existing libHSghcFri, 29 Jul 2011 12:16:14 GMTbatterseapower<p>
This ticket split out from <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3843" title="task: Merge plugins into HEAD (closed: fixed)">#3843</a> since it was getting too crowded
</p>
<p>
Once we can safely export all symbols from libHSghc through the executable, we want to link plugins against the loaded GHC library rather than a new copy. This has two benefits:
</p>
<ol><li>Linking plugins will be faster
</li><li>We can make reinitializeGlobals into a no-op
</li></ol><p>
This is currently blocked by <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/5292" title="bug: libHSghc exports more symbols than Windows can handle (new)">#5292</a> because libHSghc exports more symbols than we can reexport on Windows. There is one suggestions in <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3843" title="task: Merge plugins into HEAD (closed: fixed)">#3843</a> to reexport less: exclude more of GHC's dependencies from being reexported, using this snippet to get the package list:
</p>
<pre class="wiki">$(foreach p,$(PACKAGES),$p-$(libraries/$p_dist-install_VERSION))
</pre><p>
Once we have cut the number of exported symbols down enough, the patches in <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3843" title="task: Merge plugins into HEAD (closed: fixed)">#3843</a>'s attachment 3843-v2.zip can be applied to fix this ticket. (There was a reported validate failure with this patch in annrun01 on x64 linux which should also be checked)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5355#changelog
http://ghc.haskell.org/trac/ghc/ticket/5392
http://ghc.haskell.org/trac/ghc/ticket/5392#5392: Warnings about impossible MPTCs would be niceMon, 08 Aug 2011 17:06:16 GMTpumpkin<p>
In the following class declaration:
</p>
<pre class="wiki">{-# LANGUAGE MultiParamTypeClasses #-}
class C a b where
f :: a -> a
</pre><p>
it is possible to declare this class, and to make instances of it, but it will be impossible to ever call <tt>f</tt>, even with <tt>unsafeCoerce</tt> and other evil attempted workarounds. It seems fairly easy for GHC to spot this situation, where a method doesn't mention all of the class arguments, and it might save some confusion for newbies. I remember trying pretty hard when I was first learning haskell to tell GHC which instance I wanted there, but obviously failed quite miserably.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5392#changelog
http://ghc.haskell.org/trac/ghc/ticket/5429
http://ghc.haskell.org/trac/ghc/ticket/5429#5429: Docase notation as GHC extensionWed, 24 Aug 2011 23:40:49 GMTtomasp<p>
Many monads provide additional combinators for <em>parallel composition</em>, <em>choice</em> and <em>aliasing</em>. In our Haskell Symposium 2011 paper (<a class="ext-link" href="http://www.cl.cam.ac.uk/~tp322/papers/docase.html"><span class="icon"></span>http://www.cl.cam.ac.uk/~tp322/papers/docase.html</a>) we call a monad with these 3 additional combinators a <strong>joinad</strong>.
</p>
<p>
The monads that implement (some of) these three operations include:
</p>
<ul><li><strong>Par monad</strong> for parallel programming implements <em>parallel composition</em> (run two computations in parallel) and <em>aliasing</em> (start computation and access the result in multiple other computations) and can be extended to support (non-deterministic) <em>choice</em>
</li><li><strong>Parsers</strong> can implement <em>parallel composition</em> as an intersection of languages (parse the same input using multiple parsers), which is useful for encoding validation rules and <em>choice</em> (use the result of a first parser that succeeds).
</li><li><strong>Other monads</strong> that can be considered include the <tt>Orc</tt> monad (for concurrent orchestration) and the encoding of CHP (Communicating Haskell Processes).
</li></ul><p>
The proposal is to implement the a GHC extension that allows the <tt>docase</tt> notation for working with <em>joinads</em>. Using the <tt>Par</tt> monad as an example, the following snippet implements a function <tt>all</tt> which tests whether a predicate holds for all leaves of a tree:
</p>
<pre class="wiki">all :: (a -> Bool) -> Tree a -> Par Bool
all p (Leaf v) = return (p v)
all p (Node left right) =
docase all p left, all p right of
False, ? -> return False
?, False -> return False
allL, allR -> return (allL && allR)
</pre><p>
The left and right sub-trees are processed in parallel (using <em>parllel composition</em>). The special pattern <tt>?</tt> denotes that the corresponding computation does not have to complete in order for the clause to match. This means that the first two clauses implement short-circuiting behavior (and can match even if the other branch is still being processed).
</p>
<p>
The operations used by the desugaring are expected to have the following types:
</p>
<ul><li><tt>mzip :: m a -> m b -> m (a, b)</tt><br />This operation has been added by the recent patch that re-implements <em>monad comprehensions</em>, so we can reuse it.
</li><li><tt>morelse :: m a -> m a -> m a</tt><br />The operation has the same type as <tt>mplus</tt> from <tt>MonadPlus</tt>, but we require an operation that is left-biased. One possible option is to add <tt>MonadOr</tt> type class as suggested in <a class="ext-link" href="http://www.haskell.org/haskellwiki/MonadPlus_reform_proposal"><span class="icon"></span>http://www.haskell.org/haskellwiki/MonadPlus_reform_proposal</a>.
</li><li><tt>malias :: m a -> m (m a)</tt><br />The operation "starts" a computation and returns a handle for accessing the result. It has been used e.g. by the authors of the <tt>Orc</tt> monad. For many simpler monads, this can be implemented as monadic <tt>return</tt>.
</li></ul><p>
===Feedback===
I would appreciate any feedback from GHC users and developers! In particular, here are some general, as well as more specific questions that I've heard in the past:
</p>
<ul><li>What existing monads can implement the interface? (I believe there are quite a few of them including <tt>Par</tt>, Parsers, <tt>Orc</tt>, CPH, but I'd love to know about more.)
</li></ul><ul><li>What to do about monads that implement only some operations? Currently, the <tt>malias</tt> operation has default implementation. If a <tt>docase</tt> notation has just a single clause, then <tt>morelse</tt> is not required. If it has multiple clauses, each having just a single <em>binding pattern</em> (non <tt>?</tt>) then <tt>mzip</tt> is not required.
</li></ul><ul><li>The laws - the paper includes detailed discussion about laws (e.g. why <tt>mzip</tt> should be symmetric and why <tt>morelse</tt> should have left-biase). Does the community agree with the laws, or do you suggest some changes?
</li></ul><ul><li>Syntax seems to be a tricky question - the notation intentionally resembles <tt>case</tt>, but it takes a list of arguments (of type <tt>m a1</tt>, ..., <tt>m an</tt>), so it is not using <em>tuple syntax</em>. Is there any better alternative?
</li></ul><ul><li>Correspondence with <em>monad comprehensions</em> - the <tt>docase</tt> notation can express parallel composition in a similar way as <em>monad comprehensions</em>. I think this parity is a good thing. However, it allows more expressivity in one direction (by adding choice) and less in another (no group/order by comprehensions). Do you think this is a good ballance?
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5429#changelog
http://ghc.haskell.org/trac/ghc/ticket/5443
http://ghc.haskell.org/trac/ghc/ticket/5443#5443: Errors when shutting down the event manager loopWed, 31 Aug 2011 07:33:35 GMTbasvandijk<p>
As explained in <a class="ext-link" href="http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/20573"><span class="icon"></span>this thread on the GHC list</a> I use the GHC event manager in my <a class="ext-link" href="https://github.com/basvandijk/usb"><span class="icon"></span>usb library</a>. I create my own <tt>EventManager</tt> and start a thread which runs the event manager loop. When the library is finalized I automatically shutdown the loop. However this causes error messages from the RTS to be printed.
</p>
<p>
The following program shows the problem in isolation:
</p>
<pre class="wiki">import Control.Concurrent
import GHC.Event
main = do
em <- new
tid <- forkIO $ loop em
threadDelay 2000000
shutdown em -- Note that 'killThread tid' has the same effect.
threadDelay 2000000
</pre><p>
Make sure to build it with <tt>-threaded</tt> enabled:
</p>
<p>
<tt>$ ghc -threaded --make eventManagerBug.hs</tt>
</p>
<p>
Running it gives the following errors:
</p>
<pre class="wiki">$ ./eventManagerBug
example: ioManagerWakeup: write: Bad file descriptor
example: ioManagerDie: write: Bad file descriptor
</pre><p>
Note that these errors are printed in the <tt>ioManagerWakeup</tt> function in <tt>rts/posix/Signals.c</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5443#changelog
http://ghc.haskell.org/trac/ghc/ticket/5444
http://ghc.haskell.org/trac/ghc/ticket/5444#5444: Slow 64-bit primops on 32 bit systemWed, 31 Aug 2011 11:05:30 GMTKhudyakov<p>
GHC primops for 64-bit arithmetic are implemented as FFI calls. It leads to serious performance penalty for 32 bit code which heavily uses 64-bit arithmetics.
</p>
<p>
I found this while investigating poor performance of mwc-random on 32-bit systems. 32-bit build runs 3-4 times slower than 64-bit build on the same hardware. It's difficult to estimate how faster would run optimal implementation since it doesn't exist. But it's probably at least 2x slowdown.
</p>
<p>
Here is simple program to demonstrate issue
</p>
<pre class="wiki">sqr64 :: Int32 -> Int64
sqr64 x = y * y where y = fromIntegral x
</pre><p>
Here is optimized core
</p>
<pre class="wiki">$wsqr64 :: Int# -> Int64
$wsqr64 =
\ (ww_sGO :: Int#) ->
case {__pkg_ccall ghc-prim hs_intToInt64 Int#
-> State# RealWorld -> (# State# RealWorld, Int64# #)}_aFY
ww_sGO realWorld#
of _ { (# _, ds2_aG2 #) ->
case {__pkg_ccall ghc-prim hs_timesInt64 Int64#
-> Int64# -> State# RealWorld -> (# State# RealWorld, Int64# #)}_aGc
ds2_aG2 ds2_aG2 realWorld#
of _ { (# _, ds4_aGi #) ->
I64# ds4_aGi
}
}
sqr64 :: Int32 -> Int64
sqr64 = \ (w_sGM :: Int32) ->
case w_sGM of _ { I32# ww_sGO -> $wsqr64 ww_sGO }
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5444#changelog
http://ghc.haskell.org/trac/ghc/ticket/5522
http://ghc.haskell.org/trac/ghc/ticket/5522#5522: mc03 -O -fliberate-case -fspec-constr runs out of memoryThu, 29 Sep 2011 02:32:47 GMTbtutt<p>
I noticed that test mc03 runs out of memory compiled with -O -fliberate-case -fspec-constr.
</p>
<p>
-O + either extra option on its own isn't enough to trigger the issue..
</p>
<p>
stage2 --info output:
</p>
<pre class="wiki">$ ../inplace/bin/ghc-stage2.exe --info
[("Project name","The Glorious Glasgow Haskell Compilation System")
,("GCC extra via C opts"," -fwrapv")
,("C compiler command","$topdir/../mingw/bin/gcc.exe")
,("C compiler flags","")
,("ar command","C:/MinGW/msys/1.0/home/bill/ghc-HEAD-github/inplace/mingw/bin/ar.exe")
,("ar flags","q")
,("ar supports at file","YES")
,("touch command","$topdir/touchy.exe")
,("dllwrap command","$topdir/../mingw/bin/dllwrap.exe")
,("windres command","$topdir/../mingw/bin/windres.exe")
,("perl command","$topdir/../perl/perl.exe")
,("Project version","7.3.20110927")
,("Booter version","7.0.2")
,("Stage","2")
,("Build platform","i386-unknown-mingw32")
,("Host platform","i386-unknown-mingw32")
,("Target platform","i386-unknown-mingw32")
,("Have interpreter","YES")
,("Object splitting supported","YES")
,("Have native code generator","YES")
,("Support SMP","YES")
,("Unregisterised","NO")
,("Tables next to code","YES")
,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn")
,("Leading underscore","YES")
,("Debug on","False")
,("LibDir","C:\\MinGW\\msys\\1.0\\home\\bill\\ghc-HEAD-github\\inplace\\lib")
,("Global Package DB","C:\\MinGW\\msys\\1.0\\home\\bill\\ghc-HEAD-github\\inplace\\lib\\package.conf.d")
,("Gcc Linker flags","[]")
,("Ld Linker flags","[]")
]
</pre><p>
ghc-HEAD was built with BuildFlavor=perf
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5522#changelog
http://ghc.haskell.org/trac/ghc/ticket/5556
http://ghc.haskell.org/trac/ghc/ticket/5556#5556: Support pin-changing on ByteArray#sThu, 13 Oct 2011 23:02:03 GMTpumpkin<p>
I'm mostly posting this here as a chance for discussion for this feature, as I've wanted it a few times before and because Roman Leshchinskiy mentioned it on reddit and reminded me.
</p>
<p>
<quoting>
</p>
<p>
IIRC, the basic idea was to have an operation like:
</p>
<pre class="wiki">pin# :: ByteArray# -> ByteArray#
</pre><p>
Then you could say:
</p>
<pre class="wiki">let y = pin# x
</pre><p>
and y would have the same contents as x but be pinned. Whether it is the same memory block as x would be implementation-dependent but with GHC, it would be. When GHC would garbage collect y, it would unpin x (if x is still alive). You would also have unpin# so if you said:
</p>
<pre class="wiki">let z = unpin# y
</pre><p>
then z will become unpinned when y is garbage collected.
</p>
<p>
</quoting>
</p>
<p>
I mostly care because it's unfortunate to have to decide up front whether you want to suffer from memory fragmentation or to support foreign bindings. This could for example let us break the distinction between Data.Vector.Unboxed and Data.Vector.Storable. From a higher level, you might have a <tt>withPinned</tt> function that would temporarily pin (without copying) an array while you make foreign calls with it (even across multiple foreign calls), and then would unpin it when you're done.
</p>
<p>
I'm not sure what this would entail on the actual GC/runtime side of things, but I figured it'd be worth discussing.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5556#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/5619
http://ghc.haskell.org/trac/ghc/ticket/5619#5619: Shorter qualified import statementsWed, 09 Nov 2011 13:32:16 GMTYvesPares<p>
I would like to be able to write imports like
</p>
<pre class="wiki">import qualified Data.Vector as V (Vector, fromList)
import Data.Vector ((!), (//))
</pre><p>
as a single statement, like
</p>
<pre class="wiki">import qualified Data.Vector ((!), (//)) as V (Vector, fromList)
</pre><p>
Which seems to be compatible with the current import statement.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5619#changelog
http://ghc.haskell.org/trac/ghc/ticket/5630
http://ghc.haskell.org/trac/ghc/ticket/5630#5630: External Core needs loveSun, 13 Nov 2011 08:04:33 GMTquux<pre class="wiki">{-# LANGUAGE GADTs #-}
data T a b where
T1 :: a -> b -> T [a] (a,b)
main = putStrLn ":("
</pre><p>
and then "ghc this.hs -fext-core"
results in
</p>
<pre class="wiki">>ghc core-sandbox.hs -fext-core
ghc core-sandbox.hs -fext-core
[1 of 1] Compiling Main ( core-sandbox.hs, core-sandbox.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.2.1 for i386-unknown-mingw32):
make_exp (App _ (Coercion _))
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5630#changelog
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/5647
http://ghc.haskell.org/trac/ghc/ticket/5647#5647: CLI option to silence "Loading package foo ... linking ... done" outputSat, 19 Nov 2011 15:46:17 GMThvr<p>
When building libraries with GHC that require compile-time evaluations, such as <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell">TemplateHaskell</a>, the per-compilation unit progress output, i.e.
</p>
<pre class="wiki">[ n of N] Compiling Foo.Bar.Doo ( ... )
</pre><p>
is flooded with several
</p>
<pre class="wiki">Loading package foo ... linking ... done.
</pre><p>
lines for each library required by the interpreted compile-time code.
</p>
<p>
Although this information is definitely useful for tracking down compile-time linking issues, its a bit too verbose IMHO.
</p>
<p>
I couldn't find any CLI option, to selectively disable just those linker messages, but keep the compilation progress output, therefore I'd hereby request the feature to provide a CLI option to disable outputting just those <tt>Loading package ...</tt> message while keeping everything else as is.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5647#changelog
http://ghc.haskell.org/trac/ghc/ticket/5692
http://ghc.haskell.org/trac/ghc/ticket/5692#5692: Source code with large floating constants in exponential notation cannot be compiledMon, 12 Dec 2011 15:32:52 GMTgracjan<p>
Source code cannot be compiled:
</p>
<pre class="wiki">main = do
print (123e124124124 :: Double)
</pre><p>
where this one can be and will work after <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/5688" title="bug: instance Read Integer/Rational/Double readsPrec out of memory and crash ... (closed: fixed)">#5688</a> is fixed:
</p>
<pre class="wiki">main = do
print (read "123e124124124" :: Double)
</pre><p>
Haskell Report forces Float and Double to go through Rational:
</p>
<p>
<a class="ext-link" href="http://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1360006.4.1"><span class="icon"></span>http://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1360006.4.1</a>
</p>
<p>
When exponent is big it produces very large Rational numbers. That takes a lot of time and usually ends in out of memory condition.
</p>
<p>
This is similar to <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/5688" title="bug: instance Read Integer/Rational/Double readsPrec out of memory and crash ... (closed: fixed)">#5688</a>, but at compile time.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5692#changelog
http://ghc.haskell.org/trac/ghc/ticket/5775
http://ghc.haskell.org/trac/ghc/ticket/5775#5775: Inconsistency in demand analysisSat, 14 Jan 2012 19:43:24 GMTrl<p>
A small program:
</p>
<pre class="wiki">{-# LANGUAGE MagicHash, UnboxedTuples #-}
module U where
import GHC.Prim
import GHC.Types
idx :: Addr# -> Int -> Int
{-# INLINE idx #-}
idx a (I# i) = case readIntOffAddr# a i realWorld# of (# _, y #) -> I# y
f :: Int -> Int -> Int
{-# INLINE f #-}
f x y = y + x
foo :: Addr# -> Int -> Int
foo a n = n `seq` loop (idx a 0) 1
where
loop x i = case i >= n of
False -> loop (f x (idx a i)) (i+1)
True -> x
</pre><p>
GHC infers the demand <tt>LU(L)</tt> for <tt>loop</tt>, only unboxes the second argument, ultimately generates a loop of type <tt>Int -> Int# -> Int</tt> and always allocates a thunk for the first argument:
</p>
<pre class="wiki"> $wloop_si9 [Occ=LoopBreaker] :: Int -> Int# -> Int
[LclId, Arity=2, Str=DmdType LL]
$wloop_si9 =
\ (w1_shU :: Int) (ww1_shX :: Int#) ->
case >=# ww1_shX ww_si5 of _ {
False ->
$wloop_si9
(case readIntOffAddr# @ RealWorld w_si2 ww1_shX realWorld#
of _ { (# _, y_a9S #) ->
case w1_shU of _ { I# y1_ahb -> I# (+# y_a9S y1_ahb) }
})
(+# ww1_shX 1);
True -> w1_shU
}; }
</pre><p>
But if I change the pragma on <tt>f</tt> from <tt>INLINE</tt> to <tt>NOINLINE</tt>, <tt>loop</tt> gets the demand <tt>U(L)U(L)m</tt> and GHC manages to unbox both arguments as well as the result, producing a nice tight loop:
</p>
<pre class="wiki"> $wloop_sii [Occ=LoopBreaker] :: Int# -> Int# -> Int#
[LclId, Arity=2, Str=DmdType LL]
$wloop_sii =
\ (ww1_shW :: Int#) (ww2_si0 :: Int#) ->
case >=# ww2_si0 ww_sib of _ {
False ->
case readIntOffAddr# @ RealWorld w_si8 ww2_si0 realWorld#
of _ { (# _, y1_Xac #) ->
case f (I# ww1_shW) (I# y1_Xac) of _ { I# ww3_Xin ->
$wloop_sii ww3_Xin (+# ww2_si0 1)
}
};
True -> ww1_shW
}; }
</pre><p>
It would be nice if this happened in both cases.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5775#changelog
http://ghc.haskell.org/trac/ghc/ticket/5777
http://ghc.haskell.org/trac/ghc/ticket/5777#5777: core lint error with arrow notation and GADTsSun, 15 Jan 2012 16:11:24 GMTbenmos<p>
The following code panics GHC (with 7.0.3, 7.2 and 7.4.0.20111219):
</p>
<pre class="wiki">{-# LANGUAGE Arrows, GADTs #-}
import Control.Arrow
data Value a where BoolVal :: Value Bool
class ArrowInit f where
arrif :: f b -> ()
instance ArrowInit Value where
arrif = proc BoolVal -> returnA -< ()
-- arrif = arr (\BoolVal -> ())
</pre><p>
I am attaching the -dcore-lint from 7.4.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5777#changelog
http://ghc.haskell.org/trac/ghc/ticket/5791
http://ghc.haskell.org/trac/ghc/ticket/5791#5791: Defer other kinds of errors until runtime, not just type errorsTue, 17 Jan 2012 16:57:05 GMTsimonmar<p>
In <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/5624" title="feature request: Delay Errors Until Runtime (closed: fixed)">#5624</a> we added <tt>-fdefer-type-errors</tt> to turn type errors into warnings. We can do this for other kinds of errors too, notably out-of-scope errors, and there are plenty more errors that can be deferred by replacing the erroneous subexpression by a call to <tt>error</tt>. See also <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1341" title="feature request: allow loading partially correct modules (closed: duplicate)">#1341</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5791#changelog
http://ghc.haskell.org/trac/ghc/ticket/5813
http://ghc.haskell.org/trac/ghc/ticket/5813#5813: Offer a compiler warning for failable pattern matchesTue, 24 Jan 2012 10:30:20 GMTsnoyberg<p>
This started off with a mailing list discussion: <a class="ext-link" href="http://www.mail-archive.com/haskell-cafe@haskell.org/msg96517.html"><span class="icon"></span>http://www.mail-archive.com/haskell-cafe@haskell.org/msg96517.html</a>. The problem is that the following code produces no compile-time warning and results in a runtime error:
</p>
<pre class="wiki">data MyType = Foo | Bar
deriving Show
test :: Monad m => m MyType -> m ()
test myType = do
Foo <- myType
return ()
main :: IO ()
main = test $ return Bar
</pre><p>
This is in contrast to the rest of pattern matching, which would warn about unmatched patterns, e.g.:
</p>
<pre class="wiki">data MyType = Foo | Bar
deriving Show
test :: Monad m => m MyType -> m ()
test myType = do
x <- myType
case x of
Foo -> return ()
main :: IO ()
main = test $ return Bar
</pre><p>
I understand that this style of code may be very useful in some circumstances when paired with a Monad providing a sensible fail implementation, and is especially used in list comprehensions. However, this is allowing an easily catchable static error to slip through our fingers.
</p>
<p>
I recommend we add a new compiler warning to catch incomplete patterns in do-notation binding. I believe this warning should not apply to list comprehensions. Ideally, this warning would be turned on by -Wall.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5813#changelog
http://ghc.haskell.org/trac/ghc/ticket/5821
http://ghc.haskell.org/trac/ghc/ticket/5821#5821: SPECIALISE fails with a cryptic warningFri, 27 Jan 2012 23:26:36 GMTrl<p>
Example:
</p>
<pre class="wiki">type family T a
type instance T Int = Bool
foo :: Num a => a -> T a
foo = undefined
{-# SPECIALISE foo :: Int -> Bool #-}
</pre><p>
GHC produces this warning:
</p>
<pre class="wiki"> RULE left-hand side too complicated to desugar
case cobox of _ { GHC.Types.Eq# cobox ->
(foo @ Int $dNum)
`cast` (<Int> -> cobox :: (Int -> T Int) ~# (Int -> Bool))
}
</pre><p>
Given that rewrite rules don't reliably work in the presence of type families, I somewhat suspect that GHC won't be able to generate a sensible specialisation here but it should produce a better diagnostic.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5821#changelog
http://ghc.haskell.org/trac/ghc/ticket/5823
http://ghc.haskell.org/trac/ghc/ticket/5823#5823: FFI and CAPI needs {-# INCLUDE #-} back?Sat, 28 Jan 2012 20:01:13 GMTigloo<p>
Now that we have CAPI, do we want <tt>{-# INCLUDE #-}</tt> back?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5823#changelog
http://ghc.haskell.org/trac/ghc/ticket/5834
http://ghc.haskell.org/trac/ghc/ticket/5834#5834: Allow both INLINE and INLINABLE for the same functionMon, 30 Jan 2012 21:45:08 GMTrl<p>
Sometimes you really want both. Here is a small example:
</p>
<pre class="wiki">module T where
foo :: Num a => a -> a -> a
foo x y = x+y+1
</pre><pre class="wiki">module U where
import T
appl :: (a -> b) -> a -> b
{-# NOINLINE appl #-}
appl f x = f x
bar :: Int -> Int -> Int
bar x y = appl foo x y
</pre><p>
If I mark <tt>foo</tt> as <tt>INLINE</tt>, then GHC generates this code for <tt>bar</tt>:
</p>
<pre class="wiki">bar1 :: Int -> Int -> Int
bar1 = foo @ Int $fNumInt
bar :: Int -> Int -> Int
bar = \ (x_aa0 :: Int) (y_aa1 :: Int) -> appl @ Int @ (Int -> Int) bar1 x_aa0 y_aa1
</pre><p>
Whereas with <tt>INLINABLE</tt>, we get a nice specialisation but, of course, not guarantees with respect to inlining.
</p>
<p>
In general, it seems that requiring a function to inline when it is saturated and requiring it two specialise when it isn't are two different things and shouldn't be mutually exclusive.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5834#changelog
http://ghc.haskell.org/trac/ghc/ticket/5835
http://ghc.haskell.org/trac/ghc/ticket/5835#5835: Make better use of known dictionariesMon, 30 Jan 2012 22:02:11 GMTrl<p>
Example:
</p>
<pre class="wiki">data T a where
T :: Eq a => a -> T a
foo :: a -> T a -> Bool
{-# INLINE foo #-}
foo x = \(T y) -> x == y
appl :: (a -> b) -> a -> b
{-# NOINLINE appl #-}
appl f x = f x
bar :: T Int -> Bool
bar t = appl (foo 42) t
</pre><p>
GHC generates this for <tt>bar</tt>:
</p>
<pre class="wiki">bar2 :: Int
bar2 = I# 42
bar1 :: T Int -> Bool
bar1 =
\ (ds_dhk :: T Int) ->
case ds_dhk of _ { T $dEq_agz y_aa4 ->
== @ Int $dEq_agz bar2 y_aa4
}
bar :: T Int -> Bool
bar = \ (t_aga :: T Int) -> appl @ (T Int) @ Bool bar1 t_aga
</pre><p>
Note how it want to get the <tt>Eq</tt> dictionary for <tt>Int</tt> from <tt>T</tt>. But we know the <tt>Eq Int</tt> instance without inspecting <tt>T</tt> and <tt>bar</tt> could be significantly simplified if we used that.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5835#changelog
http://ghc.haskell.org/trac/ghc/ticket/5841
http://ghc.haskell.org/trac/ghc/ticket/5841#5841: seg fault in ghci but not ghc when using chart-gtk codeFri, 03 Feb 2012 16:44:50 GMTcarter<p>
I don't know if this is os x lion specific,
but when running (attached .hs file) after compiling with (attached .txt) directions,
the program compiled with ghc to a binary will work when set to generate
either a pdf or a x11 window. In contrast, the same program when run via ghci and set to render to an x11 window, it segfaults. The ghci run when set to output to pdf works fine though. So I think the problem (perhaps, but perhaps not) might be with how the gtk package uses the ffi when run via ghci vs ghc? (so perhaps is a static vs dynamic linking issue).
</p>
<p>
it does seem like this might in some way related to another linking bug on mac
<a class="ext-link" href="http://hackage.haskell.org/trac/ghc/ticket/5816#comment:4"><span class="icon"></span>http://hackage.haskell.org/trac/ghc/ticket/5816#comment:4</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5841#changelog
http://ghc.haskell.org/trac/ghc/ticket/5898
http://ghc.haskell.org/trac/ghc/ticket/5898#5898: ghc: internal error: Invalid Mach-O fileSun, 26 Feb 2012 21:39:34 GMTjeffshaw<p>
I am running Mac OS 10.5.8 on a PowerPC processor.
</p>
<pre class="wiki">$ cabal --version
cabal-install version 0.10.2
using version 1.10.2.0 of the Cabal library
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.4
$ machine
ppc7450
</pre><p>
<tt>cabal install yesod-core</tt> fails with
</p>
<pre class="wiki">Loading package wai-logger-0.1.4 ... linking ... ghc: internal error: Invalid Mach-O file:Address out of bounds while relocating object file
(GHC version 7.0.4 for powerpc_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5898#changelog
http://ghc.haskell.org/trac/ghc/ticket/5916
http://ghc.haskell.org/trac/ghc/ticket/5916#5916: runST isn't freeMon, 05 Mar 2012 16:23:25 GMTtibbe<p>
While optimizing some code I discovered that <tt>runST</tt> isn't free. I had a function on the form:
</p>
<pre class="wiki">f ... = ...let x = runST in (f x)...
</pre><p>
Manually transforming it into
</p>
<pre class="wiki">f ... = runST (g ...)
where g ... = do
...
x <- ...
g x
...
</pre><p>
(The real example is at <a class="ext-link" href="https://github.com/tibbe/unordered-containers/commit/58b7815a057b3575c58b746d5971d59d806b1333"><span class="icon"></span>https://github.com/tibbe/unordered-containers/commit/58b7815a057b3575c58b746d5971d59d806b1333</a>)
</p>
<p>
improved performance quite a bit on this, already highly tuned, function. Unfortunately, combining all the calls to <tt>runST</tt> into one and pulling them "up" is not all good. The code is now less modular, has a somewhat over specified evaluation order, and generally looks more imperative.
</p>
<p>
The cause of the decrease in performance is that <tt>runSTRep</tt> cannot be inlined, which causes allocation of closures inline in the code (where none should be necessary.)
</p>
<p>
The comment next to <tt>runSTRep</tt> explains why it's implemented the way it is, but I wonder if matters could be improved by making it a primop. If we create a fresh state token every time, instead of reusing <tt>realWorld#</tt>, it should be impossible for mutable structures to let-float and become CAFs (which is what <tt>runSTRep</tt> tries to avoid.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5916#changelog
http://ghc.haskell.org/trac/ghc/ticket/5924
http://ghc.haskell.org/trac/ghc/ticket/5924#5924: Bad Cmm generated for updating one element in Array#Fri, 09 Mar 2012 23:56:39 GMTtibbe<p>
I've attached a small standalone program that implements the following function:
</p>
<pre class="wiki">-- | /O(n)/ Update the element at the given position in this array.
update16 :: Array e -> Int -> e -> Array e
</pre><p>
which update one element (by copying the whole array) of an array of size 16. The attachment includes the optimized Cmm for a call to this function, together with a bunch of comments (inline with the Cmm) by me, pointing out inefficiencies in the generated Cmm.
</p>
<p>
My overall goal is to make this particular function fast. This might involve fixes to the code generator and/or adding primitives whether that makes sense. In any case this code might be a good source of ideas for improvements to the code generator.
</p>
<p>
To follow my annotations, start at <tt>Update.test_info</tt> in <tt>Update.cmm</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5924#changelog
http://ghc.haskell.org/trac/ghc/ticket/5928
http://ghc.haskell.org/trac/ghc/ticket/5928#5928: INLINABLE fails to specialize in presence of simple wrapperSun, 11 Mar 2012 17:29:08 GMTtibbe<p>
If a function marked as <tt>INLINABLE</tt> is called indirectly through a simple wrapper defined in a different module, specialization never happens (i.e. none of the dictionaries are removed.)
</p>
<p>
Here's an example where it fails. First, the simple wrapper module:
</p>
<pre class="wiki">module Repro where
import Data.Hashable
import Data.HashMap.Strict as M
infixl 9 !
(!) :: (Eq a, Hashable a) => M.HashMap a b -> a -> b
m ! x = case M.lookup x m of -- lookup is INLINABLE
Just y -> y
Nothing -> error "Repro.!"
</pre><p>
and then the call site:
</p>
<pre class="wiki">module Test (test) where
import Data.HashMap.Strict as M
import Repro
test :: M.HashMap Int Int -> Int
test m = m ! 42
</pre><p>
To compile the code you need to <tt>cabal install unordered-containers</tt>. The relevant function (which is not getting specialized) from unordered-containers is:
</p>
<pre class="wiki">lookup :: (Eq k, Hashable k) => k -> HashMap k v -> Maybe v
lookup k0 = go h0 k0 0
where
h0 = hash k0
go !_ !_ !_ Empty = Nothing
go h k _ (Leaf hx (L kx x))
| h == hx && k == kx = Just x
| otherwise = Nothing
go h k s (BitmapIndexed b v)
| b .&. m == 0 = Nothing
| otherwise = go h k (s+bitsPerSubkey) (A.index v (sparseIndex b m))
where m = mask h s
go h k s (Full v) = go h k (s+bitsPerSubkey) (A.index v (index h s))
go h k _ (Collision hx v)
| h == hx = lookupInArray k v
| otherwise = Nothing
#if __GLASGOW_HASKELL__ >= 700
{-# INLINABLE lookup #-}
#endif
</pre><p>
If <tt>test</tt> calls <tt>lookup</tt> directly, without using the <tt>(!)</tt> wrapper, things get specialized. Manually marking <tt>(!)</tt> as <tt>INLINABLE</tt> works, but users shouldn't have to do that.
</p>
<p>
The core for <tt>Repro</tt> and <tt>Test</tt> is:
</p>
<pre class="wiki">$ ghc -O2 Test.hs -fforce-recomp -ddump-simpl
[1 of 2] Compiling Repro ( Repro.hs, Repro.o )
==================== Tidy Core ====================
Result size = 28
lvl_rNZ :: [GHC.Types.Char]
[GblId]
lvl_rNZ = GHC.CString.unpackCString# "Repro.!"
Repro.!1 :: forall b_aBU. b_aBU
[GblId, Str=DmdType b]
Repro.!1 = \ (@ b_aBU) -> GHC.Err.error @ b_aBU lvl_rNZ
Repro.!
:: forall a_atJ b_atK.
(GHC.Classes.Eq a_atJ, Data.Hashable.Hashable a_atJ) =>
Data.HashMap.Base.HashMap a_atJ b_atK -> a_atJ -> b_atK
[GblId,
Arity=4,
Str=DmdType LLLL,
Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=4, Value=True,
ConLike=True, Cheap=True, Expandable=True,
Guidance=IF_ARGS [0 0 0 0] 70 0}]
Repro.! =
\ (@ a_aBT)
(@ b_aBU)
($dEq_aBV :: GHC.Classes.Eq a_aBT)
($dHashable_aBW :: Data.Hashable.Hashable a_aBT)
(m_atL :: Data.HashMap.Base.HashMap a_aBT b_aBU)
(x_atM :: a_aBT) ->
case Data.HashMap.Base.lookup
@ a_aBT @ b_aBU $dEq_aBV $dHashable_aBW x_atM m_atL
of _ {
Data.Maybe.Nothing -> Repro.!1 @ b_aBU;
Data.Maybe.Just y_atN -> y_atN
}
[2 of 2] Compiling Test ( Test.hs, Test.o )
==================== Tidy Core ====================
Result size = 20
Test.test2 :: GHC.Types.Int
[GblId,
Caf=NoCafRefs,
Str=DmdType m,
Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True,
ConLike=True, Cheap=True, Expandable=True,
Guidance=IF_ARGS [] 10 110}]
Test.test2 = GHC.Types.I# 42
Test.test1
:: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int
-> Data.Maybe.Maybe GHC.Types.Int
[GblId,
Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False,
ConLike=False, Cheap=False, Expandable=False,
Guidance=IF_ARGS [] 40 0}]
Test.test1 =
Data.HashMap.Base.lookup
@ GHC.Types.Int
@ GHC.Types.Int
GHC.Classes.$fEqInt
Data.Hashable.$fHashableInt
Test.test2
Test.test
:: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int
-> GHC.Types.Int
[GblId,
Arity=1,
Str=DmdType L,
Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True,
ConLike=True, Cheap=True, Expandable=True,
Guidance=IF_ARGS [0] 40 0}]
Test.test =
\ (m_aPx
:: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int) ->
case Test.test1 m_aPx of _ {
Data.Maybe.Nothing -> Repro.!1 @ GHC.Types.Int;
Data.Maybe.Just y_atN -> y_atN
}
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5928#changelog
http://ghc.haskell.org/trac/ghc/ticket/5985
http://ghc.haskell.org/trac/ghc/ticket/5985#5985: Type operators are not accepted as variables in contextsMon, 02 Apr 2012 14:52:05 GMTmikhail.vorozhtsov<p>
The following code is accepted by 7.4.1 (and 7.2/7.0/6.12), but rejected by HEAD:
</p>
<pre class="wiki">$ ghci-7.5.20120402 -XTypeOperators
GHCi, version 7.5.20120402: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
λ> import Control.Category
λ> let f :: Category (->>) => (a ->> b); f = undefined
<interactive>:3:19: Not in scope: type constructor or class `->>'
<interactive>:3:31: Not in scope: type constructor or class `->>'
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5985#changelog
http://ghc.haskell.org/trac/ghc/ticket/6047
http://ghc.haskell.org/trac/ghc/ticket/6047#6047: GHC retains unnecessary bindingThu, 26 Apr 2012 08:13:23 GMTsimonmar<p>
milan posted this example on <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/6042" title="bug: GHC is bloated (closed: invalid)">#6042</a>, I'm making a separate ticket for it. He says:
</p>
<hr />
<p>
BTW, when I preparing for the advanced functional programming course, I found out that the following code
</p>
<pre class="wiki">module Test where
factorial :: Int -> Int
factorial n | n > 0 = f n 1
where f 0 acc = acc
f n acc = f (n-1) (n * acc)
</pre><p>
produces the following STG, on both GHC 7.0.4 and 7.4.1, with unused method <tt>factorial_f</tt>:
</p>
<pre class="wiki">Test.factorial2 =
\u srt:(0,*bitmap*) []
Control.Exception.Base.patError
"a.hs:(4,1)-(6,35)|function factorial";
SRT(Test.factorial2): [Control.Exception.Base.patError]
Test.$wf =
\r [ww_srk ww1_sro]
case ww_srk of wild_srm {
__DEFAULT ->
case *# [wild_srm ww1_sro] of sat_srK {
__DEFAULT ->
case -# [wild_srm 1] of sat_srL {
__DEFAULT -> Test.$wf sat_srL sat_srK;
};
};
0 -> ww1_sro;
};
SRT(Test.$wf): []
Test.factorial_f =
\r [w_srs w1_srv]
case w_srs of w2_srN {
GHC.Types.I# ww_sry ->
case w1_srv of w3_srM {
GHC.Types.I# ww1_srz ->
case Test.$wf ww_sry ww1_srz of ww2_srB {
__DEFAULT -> GHC.Types.I# [ww2_srB];
};
};
};
SRT(Test.factorial_f): []
Test.factorial1 = NO_CCS GHC.Types.I#! [1];
SRT(Test.factorial1): []
Test.factorial =
\r srt:(0,*bitmap*) [n_srD]
case n_srD of wild_srP {
GHC.Types.I# x_srG ->
case ># [x_srG 0] of wild1_srO {
GHC.Types.False -> Test.factorial2;
GHC.Types.True ->
case Test.$wf x_srG 1 of ww_srJ {
__DEFAULT -> GHC.Types.I# [ww_srJ];
};
};
};
SRT(Test.factorial): [Test.factorial2]
</pre><p>
The <tt>Test.factorial_f</tt> appears also in asm and in the object file.
</p>
<hr />
<p>
simonpj explained to me why this is happening: <tt>factorial_f</tt> is being retained because it is referenced in an INLINE pragma for <tt>factorial</tt>. In fact it will never be used, because <tt>factorial_f</tt> itself is also INLINE.
</p>
<p>
We're going to investigate possible workarounds/solutions.
</p>
<p>
Note it's only a code size issue, performance is not affected (compile time is affected a little though). We're not sure how much it happens.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/6047#changelog
http://ghc.haskell.org/trac/ghc/ticket/6087
http://ghc.haskell.org/trac/ghc/ticket/6087#6087: Join points need strictness analysisThu, 10 May 2012 12:05:36 GMTsimonpj<p>
I came across this code in the <tt>nofib/spectral</tt> progam <tt>knights</tt>, in the code for <tt>KnightHeuristic.possibleMoves</tt>:
</p>
<pre class="wiki">let {
$j_sU3
:: GHC.Types.Int -> GHC.Types.Int -> [KnightHeuristic.Direction]
[LclId, Arity=2]
$j_sU3 =
\ (ww2_sRl :: GHC.Types.Int) (ww3_sRm :: GHC.Types.Int) ->
case ww2_sRl of ww4_XQY { GHC.Types.I# ww5_sQU ->
case GHC.Prim.>=# ww5_sQU 1 of _ {
GHC.Types.False -> go1_azF ys_azM;
GHC.Types.True ->
case ds1_azR of _ { GHC.Types.I# y1_azp ->
case GHC.Prim.<=# ww5_sQU y1_azp of _ {
GHC.Types.False -> go1_azF ys_azM;
GHC.Types.True ->
case ww3_sRm of wild6_XAB { GHC.Types.I# x_XAE ->
case GHC.Prim.>=# x_XAE 1 of _ {
GHC.Types.False -> go1_azF ys_azM;
GHC.Types.True ->
case GHC.Prim.<=# x_XAE y1_azp of _ {
GHC.Types.False -> go1_azF ys_azM;
GHC.Types.True ->
case GHC.List.notElem
@ ChessSetList.Tile
ChessSetList.isSquareFree_$dEq
(ww4_XQY, wild6_XAB)
wild2_azW
of _ {
GHC.Types.False -> go1_azF ys_azM;
GHC.Types.True ->
GHC.Types.:
@ KnightHeuristic.Direction y_azL (go1_azF ys_azM)
}
}
}
}
}
}
}
} } in
case y_azL of _ {
KnightHeuristic.UL ->
$j_sU3
(case ww_sQJ of _ { GHC.Types.I# x_aya ->
GHC.Types.I# (GHC.Prim.-# x_aya 1)
})
(case ww1_sQK of _ { GHC.Types.I# x_aya ->
GHC.Types.I# (GHC.Prim.-# x_aya 2)
});
KnightHeuristic.UR ->
$j_sU3
(case ww_sQJ of _ { GHC.Types.I# x_ayl ->
GHC.Types.I# (GHC.Prim.+# x_ayl 1)
})
(case ww1_sQK of _ { GHC.Types.I# x_aya ->
GHC.Types.I# (GHC.Prim.-# x_aya 2)
});
...lots more similar case alternatives follow...
</pre><p>
Just look at all those <tt>Int</tt>s getting boxed, and the immediately unboxed by the join point! The strictness analyser would spot this easily, but presumably the join point is constructed after strictness analysis.
</p>
<p>
There must be an opportunity here to run a later strictness analysis pass.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/6087#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/1498
http://ghc.haskell.org/trac/ghc/ticket/1498#1498: Optimisation: eliminate unnecessary heap check in recursive functionFri, 06 Jul 2007 08:47:42 GMTsimonmar<p>
See <a class="ext-link" href="http://www.haskell.org/pipermail/cvs-ghc/2007-July/036496.html"><span class="icon"></span>http://www.haskell.org/pipermail/cvs-ghc/2007-July/036496.html</a>
</p>
<p>
In a basic block consisting of some primitive cases, in which only some branches require heap, we could push the heap check into the branches as long as the primitive operations are safe to repeat, and the stack has not been modified. This might save a heap check in the common recursive case, which could be a significant win.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1498#changelog
http://ghc.haskell.org/trac/ghc/ticket/3372
http://ghc.haskell.org/trac/ghc/ticket/3372#3372: Allow for multiple linker instancesTue, 14 Jul 2009 22:25:01 GMTjcpetruzza<p>
Right now there is only one RTS linker with a single symbol table.This means, for example, that one cannot have multiple instances of the GHC interpreter in the same process running simultaneously.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3372#changelog
http://ghc.haskell.org/trac/ghc/ticket/3427
http://ghc.haskell.org/trac/ghc/ticket/3427#3427: control what sort of entity a deprecated pragma applies toWed, 12 Aug 2009 20:05:08 GMTigloo<p>
Originally reported as part of <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3303" title="merge: Allow multi-line deprecation messages. (closed: fixed)">#3303</a>.
</p>
<hr />
<p>
It's annoying not being able to control whether a type or identically named constructor is being deprecated. Consider:
</p>
<pre class="wiki">data Foo = Foo ...
</pre><p>
This is a very common idiom. But now we want to switch to smart constructors
</p>
<pre class="wiki">foo :: ... -> Foo
</pre><p>
and eventually stop exporting the constructor Foo. But we cannot specify just the constructor, only both. According to the <a class="ext-link" href="http://haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning-deprecated-pragma"><span class="icon"></span>user guide</a> the workaround would be to have a module that imports one but not the other, however while that's possible for the type it's not possible for the constructor.
</p>
<p>
How about
</p>
<pre class="wiki">{-# DEPRECATED constructor Foo "use `foo' instead" #-}
</pre><p>
and while we're at it, might as well have
</p>
<pre class="wiki">{-# DEPRECATED type Foo "..." #-}
</pre><p>
leaving the unqualified case meaning both as it does now.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3427#changelog
http://ghc.haskell.org/trac/ghc/ticket/3462
http://ghc.haskell.org/trac/ghc/ticket/3462#3462: New codegen: allocate large objects using allocateLocal()Tue, 25 Aug 2009 08:48:42 GMTsimonmar<p>
See <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3424" title="bug: Corrupt executable when compiling large do block for List monad (closed: fixed)">#3424</a>.
</p>
<p>
In the new code generator, we should allocate large objects (larger than F * block size, for some suitable fraction F) using the RTS <tt>allocateLocal()</tt> API rather than from the nursery. It works to allocate them from the nursery -- this is what GHC 6.12 does after the fix in <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3424" title="bug: Corrupt executable when compiling large do block for List monad (closed: fixed)">#3424</a> -- but then they will not be treated as large objects and will be copied during GC. Also, the allocation is likely to fail, requiring a trip through the RTS to put a large enough block in the nursery to satisfy the allocation.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3462#changelog
http://ghc.haskell.org/trac/ghc/ticket/3483
http://ghc.haskell.org/trac/ghc/ticket/3483#3483: Some mechanism for eliminating "absurd" patternsThu, 03 Sep 2009 01:09:00 GMTryani<p>
This is to help with type-level programming and doing dependent-like programming in Haskell.
</p>
<pre class="wiki">data TEq :: * -> * -> * where
TEq :: TEq a a
-- This declaration fails to compile because bringing (Int ~ Bool)
-- into scope on the RHS is unsound.
broken :: TEq Int Bool -> Int
broken TEq = 1
-- Proposal:
-- "!" replaces "=" in function declaration to say "this pattern is absurd"
proposal :: TEq Int Bool -> r
proposal TEq !
-- If, for some reason the pattern match succeeds,
-- (basically, someone broke type safety with unsafeCoerce)
-- the result could be something like calling:
-- error "absurd pattern at FILE:LINE"
</pre><p>
I'm not sure that "!" works with Haskell's syntax, but it does call attention to the pattern.
</p>
<p>
The idea is that anywhere that putting "= some_rhs" would cause the compiler to fail because it can prove that the type environment is unsound in some fashion, you could use "!" to give a valid function definition.
</p>
<p>
The same extension would be used for case statements, of course.
</p>
<p>
See also <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/2006" title="bug: unreachable GADT pattern clauses show up as warnings with -Wall (closed: fixed)">#2006</a>, which is related in spirit if not in implementation.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3483#changelog
http://ghc.haskell.org/trac/ghc/ticket/3547
http://ghc.haskell.org/trac/ghc/ticket/3547#3547: Improve granularity of UndecidableInstancesMon, 28 Sep 2009 12:00:29 GMTksf<p>
Currently, as a LANGUAGE pragma, UndecidableInstances can only be set once per file: Assuming that there are enough occasions where one would only need to enable it for one or two instances in a bigger source and considering that the warnings emitted if UndecidableInstances is not set are actually useful, it makes sense to support enabling the extension only on a per-instance basis.
</p>
<p>
proposed syntax:
</p>
<pre class="wiki">{-# LANGUAGE UndecidableInstances #-}
[code]
{-# NOLANGUAGE UndecidableInstances #-}
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3547#changelog
http://ghc.haskell.org/trac/ghc/ticket/3588
http://ghc.haskell.org/trac/ghc/ticket/3588#3588: ghc -M should emit dependencies on CPP headersThu, 15 Oct 2009 11:53:00 GMTsimonmar<p>
When using CPP, ghc -M should emit dependencies on header files that are <tt>#included</tt> into Haskell source code. It could do this by running <tt>gcc -M</tt>, perhaps.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3588#changelog
http://ghc.haskell.org/trac/ghc/ticket/3619
http://ghc.haskell.org/trac/ghc/ticket/3619#3619: allow to set ghc search path globally (a'la CPATH)Wed, 28 Oct 2009 13:48:12 GMTtari3x<blockquote>
<p>
I'd like a mechanism for ghc similar to setting the CPATH variable for gcc. I'd like ghc to look in the given list of paths every time it compiles something, without me having to retype the flags.
</p>
</blockquote>
<blockquote>
<p>
For ghci there is .ghci, but it gets ignored when I run ghc.
</p>
</blockquote>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3619#changelog
http://ghc.haskell.org/trac/ghc/ticket/3632
http://ghc.haskell.org/trac/ghc/ticket/3632#3632: lift restrictions on records with existential fields, especially in the presence of class constraintsMon, 02 Nov 2009 21:19:40 GMTeflister<p>
the attached file demos the use of a record with an existential field with a class constraint. it shows several cases where lifting the current restrictions on accessing and updating this field would be both well-defined and useful.
</p>
<p>
here is the record definition; the dur field is existential, but constrained to be in class NoteDur.
</p>
<pre class="wiki">data Note = forall x . NoteDur x => Note {
midiNum :: Int -- 0-255
, vel :: Int -- 0-255
, chan :: Int -- 0-15
, measure :: Integral a => a
, beat :: Int
, subdiv :: RealFrac a => a -- % of beat
, dur :: x
}
</pre><p>
here is a walk through of places in the code where the current restrictions are unnecessary and intrusive:
</p>
<ol><li>lines 64-95 -- these functions wouldn't be necessary if record update syntax were enabled for both existential and non-existential fields. i know 6.12 introduces it for non-existentials, but i don't see why it isn't also possible for existential fields (even without a class constraint). lines 33-35 and 60 show how much nicer it is to use regular updater syntax in this case.
</li></ol><ol start="2"><li>Line 142. The same is true for existential accessors when there is a class constraint -- there's no need to restrict this situation because the accessor can have type:
<pre class="wiki">fieldName :: (SomeClass x) => Record -> x
</pre>line 142 shows a case where this would be very nice to have.
</li></ol><ol start="3"><li>line 100 + 107 -- the foralls could be implicit (maybe offer an extention that would allow them to be implicit)
</li></ol><ol start="4"><li>lines 134-136 compared to 138-139 show how additional factoring could be achieved if one were allowed to pattern match on the type of an existential with class constraints.
</li></ol><ol start="5"><li>lines 124-127 show how it would be nice to have existential classes
</li></ol><ol start="6"><li>lastly, allow curried updater functions: <tt>(rec {field = }) 5</tt> instead of <tt>(\x -> (rec {field = x})) 5</tt>
</li></ol>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3632#changelog
http://ghc.haskell.org/trac/ghc/ticket/3699
http://ghc.haskell.org/trac/ghc/ticket/3699#3699: Wildcards in type functionsFri, 27 Nov 2009 10:01:09 GMTMartijnVanSteenbergen<p>
I would like to be able to use wildcards in type synonym family instances, so that I can write:
</p>
<pre class="wiki">type instance ErrorAlg (f :>: _) e a = ErrorAlg f e a
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3699#changelog
http://ghc.haskell.org/trac/ghc/ticket/3701
http://ghc.haskell.org/trac/ghc/ticket/3701#3701: allow existential wrapper newtypesSat, 28 Nov 2009 20:42:04 GMTduncan<p>
Consider this OO-style thing, a class Compiler, and a most general instance MkCompiler:
</p>
<pre class="wiki">class Compiler c where
getInstalledPackages :: c -> IO [String]
data GHC = GHC { }
data NHC = NHC { }
ghc :: GHC
ghc = GHC { }
nhc :: NHC
nhc = NHC { }
instance Compiler GHC
instance Compiler NHC
data MkCompiler where
MkCompiler :: Compiler c => c -> MkCompiler
instance Compiler MkCompiler where
getInstalledPackages (MkCompiler c) = getInstalledPackages c
compilers :: [MkCompiler]
compilers = [MkCompiler ghc, MkCompiler nhc]
</pre><p>
There's two language features we want to make this really nice:
</p>
<ol><li>Letting us call the data type <tt>Compiler</tt> rather than <tt>MkCompiler</tt>. That would mean separating the class and type namespaces.
</li><li>Letting us derive the Compiler instance for <tt>MkCompiler</tt>.
</li></ol><p>
For the latter we would want either:
</p>
<pre class="wiki">newtype MkCompiler where
MkCompiler :: Compiler c => c -> MkCompiler
deriving Compiler
</pre><p>
or
</p>
<pre class="wiki">data MkCompiler where
MkCompiler :: Compiler c => c -> MkCompiler
deriving Compiler
</pre><p>
The advantage of the first is that newtype deriving already exists as a concept so that's nice and consistent. The problem is we do not allow newtypes that use existentials. From an implementation point of view, it's clear that the representations cannot be equal because of the need to store the class dictionary. From a semantic point of view however it's not obvious that existentials with class contexts are illegitimate in newtypes. The underlying implementation would of course have to be an extra layer of boxing, so like data but with the pattern match behaviour newtype.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3701#changelog
http://ghc.haskell.org/trac/ghc/ticket/3704
http://ghc.haskell.org/trac/ghc/ticket/3704#3704: Using -shared without -dynamic should be rejected on linuxSun, 29 Nov 2009 12:26:21 GMTasuffield<p>
When trying to link with ghc -shared
</p>
<pre class="wiki">$ ghc -v -fPIC -shared -o TestF.so TestF.hs
</pre><p>
it adds a bunch of arguments of the form -lHSbase-4.2.0.0 to the linker command line
</p>
<pre class="wiki">*** Linker:
/usr/bin/gcc -v -o TestF.so TestF.o -shared -Wl,-Bsymbolic -Wl,-soname,TestF.so
-L/usr/lib/ghc-6.12.0.20091126/base-4.2.0.0 -L/usr/lib/ghc-6.12.0.20091126/integer-gmp-0.2.0.0
-L/usr/lib/ghc-6.12.0.20091126/ghc-prim-0.2.0.0 -L/usr/lib/ghc-6.12.0.20091126 -lHSbase-4.2.0.0
-lHSinteger-gmp-0.2.0.0 -lgmp -lHSghc-prim-0.2.0.0 -lHSffi
</pre><p>
Unfortunately:
</p>
<pre class="wiki">/usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0-ghc6.12.0.20091126.so
/usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0.a
/usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0_p.a
</pre><p>
The name of the .so has been mangled to include the compiler version - presumably for ABI reasons. Obviously the bug is that name on the linker command line has not been suitably mangled to match, so the linker goes ahead and tries to use the .a library, which doesn't work at all.
</p>
<pre class="wiki">/usr/bin/ld: /usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0.a(Base__76.o):
relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile
with -fPIC
</pre><p>
Tested on linux/amd64, with HEAD and stable snapshot. It may work on linux/i386 due to compatibility hacks in glibc, I haven't checked; it shouldn't work on anything else.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3704#changelog
http://ghc.haskell.org/trac/ghc/ticket/3712
http://ghc.haskell.org/trac/ghc/ticket/3712#3712: Implement -dynamic-lib optionWed, 02 Dec 2009 11:20:48 GMTsimonmar<p>
The proposal is to add a new option <tt>-dynamic-lib</tt>, to be used when building a shared library. It would be both a compile-time and a link-time option, and could be used with <tt>--make</tt> to build a complete shared library in one go. It would avoid the pitfalls caused by there being combinations of <tt>-dynamic</tt> and <tt>-fPIC</tt> don't do what the user expects.
</p>
<p>
Specifically, <tt>-dynanmic-lib</tt> would imply <tt>-dyanamic</tt>, <tt>-fPIC</tt> where necessary, and <tt>-shared</tt> when linking.
</p>
<p>
See <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3705" title="bug: -fPIC without -dynamic silently ignored (closed: wontfix)">#3705</a> for more discussion.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3712#changelog
http://ghc.haskell.org/trac/ghc/ticket/3713
http://ghc.haskell.org/trac/ghc/ticket/3713#3713: Track -dynamic/-fPIC to avoid obscure linker errorsWed, 02 Dec 2009 11:25:19 GMTsimonmar<p>
Using the wrong combination of <tt>-dynamic</tt> and/or <tt>-fPIC</tt> can lead to obscure linker errors, see e.g. <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3705" title="bug: -fPIC without -dynamic silently ignored (closed: wontfix)">#3705</a>. We should track whether an object file was compiled with <tt>-dynamic</tt> and <tt>-fPIC</tt> so that we can give better error messages before running the linker.
</p>
<p>
<strong>See also</strong>
</p><div><dl class="wiki compact"><dt><a class="new" href="/trac/ghc/ticket/3712" title="Implement -dynamic-lib option">#3712</a></dt><dd>Implement -dynamic-lib option</dd></dl></div><p>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3713#changelog
http://ghc.haskell.org/trac/ghc/ticket/3744
http://ghc.haskell.org/trac/ghc/ticket/3744#3744: Comparisons against minBound/maxBound not optimisedFri, 11 Dec 2009 03:25:59 GMTrl<pre class="wiki">foo :: Int -> Bool
foo n = n < minBound || n > maxBound
</pre><p>
GHC retains both comparisons even though they are guaranteed to be False. This also happens for other integral types. The optimisation is fairly easy to implement for <tt>Int</tt> and <tt>Word</tt> (only requires some plumbing in PrelRules) but it's not clear what to do about smaller integral types. For <tt>Int64</tt> and <tt>Word64</tt>, GHC doesn't even inline <tt>minBound</tt> and <tt>maxBound</tt>:
</p>
<pre class="wiki">T.$wfoo :: GHC.Prim.Int64# -> GHC.Bool.Bool
T.$wfoo =
\ (ww_ss5 :: GHC.Prim.Int64#) ->
case GHC.Int.$fBoundedInt64_$cminBound
of _ { GHC.Int.I64# y#_are ->
case {__ccall hs_ltInt64 GHC.Prim.Int64#
-> GHC.Prim.Int64#
-> GHC.Prim.State# GHC.Prim.RealWorld
-> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Prim.Int# #)}_arD
ww_ss5 y#_are GHC.Prim.realWorld#
of _ { (# _, ds3_arH #) ->
case ds3_arH of _ {
__DEFAULT -> GHC.Bool.True;
0 ->
case GHC.Int.$fBoundedInt64_$cmaxBound
of _ { GHC.Int.I64# y#1_ar4 ->
GHC.IntWord64.gtInt64# ww_ss5 y#1_ar4
}
}
}
}
T.foo :: GHC.Int.Int64 -> GHC.Bool.Bool
T.foo =
\ (w_ss3 :: GHC.Int.Int64) ->
case w_ss3 of _ { GHC.Int.I64# ww_ss5 -> T.$wfoo ww_ss5 }
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3744#changelog
http://ghc.haskell.org/trac/ghc/ticket/3755
http://ghc.haskell.org/trac/ghc/ticket/3755#3755: Improve join point inliningTue, 15 Dec 2009 10:57:00 GMTsimonpj<p>
This ticket relates to the paper "Optimising generics is easy" <a class="ext-link" href="http://www.dreixel.net/research/pdf/ogie.pdf"><span class="icon"></span>http://www.dreixel.net/research/pdf/ogie.pdf</a>. Jose writes (about a case where inlining doesn't work well):
</p>
<blockquote>
<p>
I put a minimal source code for this test and resulting Core
(with GHC 6.13.20091115) in <a class="ext-link" href="https://subversion.cs.uu.nl/repos/staff.jpm.public/Inline/"><span class="icon"></span>https://subversion.cs.uu.nl/repos/staff.jpm.public/Inline/</a>.
<tt>UpdateInt</tt> behaves great: in <tt>UpdateInt.core.O1.hs</tt>, there are no traces of
generic representations in testOne, testTwo, testThree and testFour.
</p>
</blockquote>
<blockquote>
<p>
<tt>UpdateString</tt>, however, does not behave so well. In <tt>UpdateString.core.O1.hs</tt>,
<tt>Test.testLogic_updateString</tt> still has loads of generic representations.
</p>
</blockquote>
<p>
It's easy to see what is happening. Compile <tt>UpdateString</tt> (which I've attached to this ticket) with <tt>-ddump-simpl</tt>, and look at the core. You see stuff like
</p>
<pre class="wiki">Rec { $j1_rx32 = \x. <big nested case expression>
; f = \y. ....($j1_rx32 <big constructor expression>)
---($j1_rx32 <big constructor expression)....
}
</pre><p>
So here the <tt>$j</tt> (which is a "join point") isn't inlined because it's big, although if it <em>were</em> inlined there would be much goodness because the case expressions would cancel with the explicit constructors.
</p>
<p>
Why did this happen despite lots of INLINE pragmas? I have not followed all the details, but I'm guessing that if we have, say
</p>
<pre class="wiki"> {-# INLINE from #-}
from = \x. case x of from_alts
{-# INLINE to #-}
to = \x. case x of to_alts
</pre><p>
and we try to optimize this call:
</p>
<pre class="wiki">from (mapT f (to x))
</pre><p>
then after inlining <tt>from</tt>, <tt>mapT</tt>, and <tt>to</tt> we'll get
</p>
<pre class="wiki">case (case (case x of to_alts) of map_alts) of from_alts
</pre><p>
And now the case-of-case transform happens, which creates the join points to avoid duplicating map_alts, from_alts into every branch of to_alts. You may say that we've already said that it's ok to duplicate from (and hence from_alts) but we duplicated it once when we inlined it, and then we forget the origin of the code. And indeed, in the worse case you could get a quadratic blow up; and there are only two functions involved. So I'm not unhappy with that.
</p>
<p>
However, it does make me wonder whether we could not do a better job on the above Rec {..}. Two thoughts occur.
</p>
<ol><li>We could beef up <tt>SpecConstr</tt>. It doesn't fire at the moment for some reason, even with -O2
</li></ol><ol start="2"><li>If we have
<pre class="wiki">f = \x. case x of { C1 x11..x1n -> e1; ... Ck xk1 ... xkm -> ek }
</pre>maybe we should worker-wrapper it to
<pre class="wiki">f1 x1 .. x1n = e1
...
fn xk1 .. xkm = en
f = \x of pi -> fi xi
</pre>and now inline f. The net effect is very similar to the way join points work right now, but it would make it multi-level. In fact, doing this might simplify and generalise the way that join points are currently done, where (rather arbitrarily) we duplicate the outer layer of a single case.
</li></ol><p>
Simon
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3755#changelog
http://ghc.haskell.org/trac/ghc/ticket/3767
http://ghc.haskell.org/trac/ghc/ticket/3767#3767: SpecConstr for join pointsWed, 16 Dec 2009 16:13:59 GMTsimonpj<p>
The attached file <tt>Spec.hs</tt> has a case (from Roman's fusion code) where <tt>SpecConstr</tt> is not doing the right thing. Let's look at one of the mutually recursive loops that <tt>SpecConstr</tt> generates for foo:
</p>
<pre class="wiki">lvl_rzY :: GHC.Types.Int
lvl_rzY = GHC.Types.I# 2147483647
lvl1_rA0 :: Data.Either.Either GHC.Types.Int GHC.Types.Int
lvl1_rA0 = Data.Either.Left @ GHC.Types.Int @ GHC.Types.Int lvl_rzY
$s$wgo_szT :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int#
$s$wgo_szT =
\ (sc_sz6 :: GHC.Prim.Int#) (sc1_sz7 :: GHC.Prim.Int#) ->
let {
$w$j_syG
:: GHC.Prim.Int#
-> Data.Either.Either GHC.Types.Int GHC.Types.Int
-> GHC.Prim.Int#
[LclId, Arity=2, Str=DmdType LS]
$w$j_syG =
\ (ww_sy6 :: GHC.Prim.Int#)
(w2_sy8 :: Data.Either.Either GHC.Types.Int GHC.Types.Int) ->
case GHC.Prim.<=# ww_sy6 0 of _ {
GHC.Bool.False -> $wgo_syE (GHC.Prim.+# sc_sz6 ww_sy6) w2_sy8;
GHC.Bool.True -> $wgo_syE sc_sz6 w2_sy8
} } in
case GHC.Prim.># sc1_sz7 0 of _ {
GHC.Bool.False -> $s$wgo1_szS sc_sz6 ipv_swo;
GHC.Bool.True ->
case sc1_sz7 of wild1_awb {
__DEFAULT ->
case GHC.Prim.remInt# wild1_awb 2 of _ {
__DEFAULT -> $s$wgo_szT sc_sz6 (GHC.Prim.-# wild1_awb 1);
0 ->
case w1_syr of _ { GHC.Types.I# ww_sy6 ->
$w$j_syG
ww_sy6
(Data.Either.Left
@ GHC.Types.Int
@ GHC.Types.Int
(GHC.Types.I# (GHC.Prim.-# wild1_awb 1)))
}
};
(-2147483648) ->
case w1_syr of _ { GHC.Types.I# ww_sy6 ->
$w$j_syG ww_sy6 lvl1_rA0
}
}
};
</pre><p>
Note that the join point has an argument of type <tt>(Either Int Int)</tt> but it is always called with <tt>(Left (I# <n>))</tt>. This means that the recursive call in the join point is always of the form <tt>($wgo_syE <m> (Left (I# <n>)))</tt> and we have a specialisation for that. However the join point itself doesn't scrutinse its argument, and that means that GHC ignores the potential specialisation.
</p>
<p>
Simon
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3767#changelog
http://ghc.haskell.org/trac/ghc/ticket/3895
http://ghc.haskell.org/trac/ghc/ticket/3895#3895: "Fix" pervasive-but-unnecessary signedness in GHC.PrimMon, 22 Feb 2010 20:51:28 GMTpumpkin<p>
I'm talking about the array primitives in particular:
</p>
<pre class="wiki">writeFloatArray# :: MutableByteArray# s -> Int# -> Float# -> State# s -> State# s
</pre><p>
Conceptually, a Word# makes more sense as the index for all the array functions. I'm not even sure what the semantics are if the Int# is negative... is it checked? The three scenarios I can think of are:
</p>
<p>
Negativity is checked, and you get an exception.
Negativity is unchecked, and you get to write to memory that comes before your array.
Negativity is ignored, and the back-end treats the Int# like a Word# already.
</p>
<p>
I think the switch would be worthwhile in all of those cases, and could be hidden in higher-level APIs that still use Int for indexes with a simple int2Word#. Eventually we might even migrate to Word-based APIs at that level?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3895#changelog
http://ghc.haskell.org/trac/ghc/ticket/3990
http://ghc.haskell.org/trac/ghc/ticket/3990#3990: UNPACK doesn't unbox data familiesWed, 14 Apr 2010 13:29:07 GMTrl<p>
Here is an example:
</p>
<pre class="wiki">data family Complex a
data instance Complex Double = CD {-# UNPACK #-} !Double
{-# UNPACK #-} !Double
data T = T {-# UNPACK #-} !(Complex Double)
</pre><p>
We would like T to just store two Double# but that doesn't happen. Contrast this with
</p>
<pre class="wiki">data Complex_Double = CD {-# UNPACK #-} !Double
{-# UNPACK #-} !Double
data T = T {-# UNPACK #-} !Complex_Double
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3990#changelog
http://ghc.haskell.org/trac/ghc/ticket/4016
http://ghc.haskell.org/trac/ghc/ticket/4016#4016: Strange display behaviour in GHCiMon, 26 Apr 2010 10:08:57 GMTsimonpj<p>
Kazu encountered another GHCi oddity. Try ":browse Prelude" in GHCi. With 6.12 we get
</p>
<pre class="wiki">data Integer
= integer-gmp:GHC.Integer.Type.S# GHC.Prim.Int#
| integer-gmp:GHC.Integer.Type.J# GHC.Prim.Int# GHC.Prim.ByteArray#
</pre><p>
Why do we get the <tt>integer-gmp:</tt> prefix? There is no ambiguity here. (GHC 6.10 didn't do this, but that's because <tt>Integer</tt> was in the <tt>base</tt> package, whereas now <tt>Integer</tt> is in <tt>integer-gmp</tt>.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4016#changelog
http://ghc.haskell.org/trac/ghc/ticket/4019
http://ghc.haskell.org/trac/ghc/ticket/4019#4019: deriving Ord can produce incorrect and inefficient instancesMon, 26 Apr 2010 15:52:54 GMTrl<p>
This bug was spotted by Barak Pearlmutter in <a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2010-April/076762.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2010-April/076762.html</a>.
</p>
<pre class="wiki">data T = T Double deriving( Eq, Ord )
*Main> T (0/0) > T (0/0)
True
*Main> (0/0) > (0/0)
False
</pre><p>
This happens because the derived Ord instance only defines compare and relies on default method definitions for everything else. Comparisons involving NaNs always return False, however, compare (arbitrarily) returns GT in this case.
</p>
<p>
Irrespective of this particular wart, this is what GHC ultimately produces for (<=):
</p>
<pre class="wiki">T.$fOrdT_$c<= =
\ (x_ahF :: T.T) (y_ahG :: T.T) ->
case x_ahF of _ { T.T a1_afL ->
case y_ahG of _ { T.T b1_afM ->
case a1_afL of _ { GHC.Types.I# x#_ah1 ->
case b1_afM of _ { GHC.Types.I# y#_ah5 ->
case GHC.Prim.<# x#_ah1 y#_ah5 of _ {
GHC.Bool.False -> GHC.Prim.==# x#_ah1 y#_ah5;
GHC.Bool.True -> GHC.Bool.True
}
}
}
}
}
</pre><p>
Note that the definition uses two comparisons even though (<=) for Double uses just one: (<=##). In general, relying on default method definitions when deriving Ord can be inefficient because the individual comparison operators might very well be faster than compare for the wrapped types.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4019#changelog
http://ghc.haskell.org/trac/ghc/ticket/4052
http://ghc.haskell.org/trac/ghc/ticket/4052#4052: Two sided sectionsFri, 07 May 2010 12:38:27 GMTaavogt<p>
Allow sections to be functions of two arguments:
</p>
<pre class="wiki">( # c ## ) a b === a # c ## b
</pre><p>
Where the associativities of <em>#</em> and <em>##</em> are then used.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4052#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/4096
http://ghc.haskell.org/trac/ghc/ticket/4096#4096: New primops for indexing: index*OffAddrUsing# etcTue, 25 May 2010 15:36:53 GMTsimonpj<p>
Here's an email from Roman, and response from Simon. Making a ticket so it's kept as an idea.
</p>
<p>
In package vector, primitive vectors (the ones that <tt>Data.Vector.Unboxed</tt> is built on top of) are represented as follows (<tt>ByteArray</tt> and friends are wrappers for various GHC primitives provided by package primitive):
</p>
<pre class="wiki">data Vector a = Vector Int -- offset into the ByteArray
Int -- length
ByteArray -- data
</pre><p>
This representation supports cheap slicing which is quite crucial. However, indexing into such vectors is a bit more expensive than necessary:
</p>
<pre class="wiki">index (Vector i _ arr) j = indexByteArray arr (i+j)
</pre><p>
Ultimately, this requires 2 additions to get the element's address:
</p>
<pre class="wiki"> <base address off the ByteArray> + ((i + j) * <size of element>)
</pre><p>
I'd like to always allocate pinned <tt>ByteArrays</tt> and store the starting address of the vector instead of the offset:
</p>
<pre class="wiki">data Vector a = Vector Addr
Int
ByteArray
</pre><p>
This would make indexing cheaper as it would require only one addition:
</p>
<pre class="wiki">index (Vector addr i _) = indexOffAddr addr i
</pre><p>
This is quite a big deal if indexing happens in an inner loop (some algorithms become up to 20% faster). Of course, the backend could optimise the offset-based version by performing partial redundancy elimination but it doesn't and it probably wouldn't get all interesting cases even if it did. So the second version is better.
</p>
<p>
The problem is that I can't implement it because I must touch the <tt>ByteArray</tt> after accessing the memory. This results in code like this which hides the constructor, breaking various optimisations:
</p>
<pre class="wiki"> case indexIntOffAddr# addr# i# of { n# ->
case touch# arr# realWorld# of { _ -> I# n# }}
</pre><p>
After thinking about this for a while, I came up with two possible solutions. One is to provide a "pure" version of touch#:
</p>
<pre class="wiki"> use# :: o -> o' -> o'
</pre><p>
such that use# x y = y. This would change the code above to:
</p>
<pre class="wiki"> I# (use# arr# (indexIntOffAddr# addr# i#))
</pre><p>
I don't know how to implement this, though, because use# would have to be able to return arbitrary (unboxed) types and the code generator doesn't really seem to support this.
</p>
<p>
A perhaps simpler solution is to add a new set of primitives:
</p>
<pre class="wiki"> indexIntOffAddrUsing# :: o -> Addr# -> Int# -> Int#
...
</pre><p>
These would take an additional argument which they'd touch and otherwise ignore. The code would then become:
</p>
<pre class="wiki"> I# (indexIntOffAddrUsing# arr# addr# i#)
</pre><p>
Incidentally, the <tt>index*OffAddr#</tt> primitives don't seem to be used anywhere. [Not true: there are a handful of uses of <tt>index*OffAddr#</tt> in libraries/base, mainly GHC.Base.]
</p>
<p>
Simon replies:
<tt>indexIntOffAddrUsing#</tt> seems like the way to go, I can't think of a better alternative.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4096#changelog
http://ghc.haskell.org/trac/ghc/ticket/4101
http://ghc.haskell.org/trac/ghc/ticket/4101#4101: Primitive constant unfoldingFri, 28 May 2010 13:50:50 GMTmalosh<p>
Examining the core generated by ghc with -O2 on a numerical code, I saw things like :
</p>
<pre class="wiki">case GHC.Prim.<## x_aB9 (GHC.Prim.**## 2.0 -1021.0) of _ {...
</pre><p>
This code being executed each time my code performs an addition ! GHC does not seem to unfold the constants right with at least <strong>##. By the way, it should definitely be possible to specify a Double# constant in hexadecimal.
</strong></p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4101#changelog
http://ghc.haskell.org/trac/ghc/ticket/4105
http://ghc.haskell.org/trac/ghc/ticket/4105#4105: ffi005 fails on OS XSat, 29 May 2010 18:43:57 GMTigloo<p>
The ffi005 test is failing on OS X x86.
</p>
<p>
The test is only run the optc way, but we get other bad results when compiling in other ways.
</p>
<p>
normal:
</p>
<pre class="wiki">{-# LANGUAGE ForeignFunctionInterface #-}
import Control.Monad
import Foreign.C
main :: IO ()
main = doit sin mysin (encodeFloat 7926335344172077 (-54))
doit :: (CDouble -> CDouble) -> (CDouble -> CDouble) -> CDouble -> IO ()
doit f g x = do let fx = f x
gx = g x
when (fx /= gx) $ do print x
print (decodeFloat x)
print fx
print gx
print (fx - gx)
foreign import ccall "sin" mysin :: CDouble -> CDouble
</pre><pre class="wiki">$ ghc q.hs -o q; ./q
0.4400000000000002
(7926335344172077,-54)
0.4259394650659998
0.42593946506599983
-5.551115123125783e-17
</pre><p>
optc:
</p>
<pre class="wiki">{-# LANGUAGE ForeignFunctionInterface #-}
import Control.Monad
import Foreign
import Foreign.C
main :: IO ()
main = do sin_addr <- wrapId sin
doit sin (dyn_sin sin_addr) (encodeFloat 7926335344172077 (-54))
freeHaskellFunPtr sin_addr
doit :: (CDouble -> CDouble) -> (CDouble -> CDouble) -> CDouble -> IO ()
doit f g x = do let fx = f x
gx = g x
when (fx /= gx) $ do print x
print (decodeFloat x)
print fx
print gx
print (fx - gx)
foreign import ccall "wrapper" wrapId :: (CDouble -> CDouble) -> IO (FunPtr (CDouble -> CDouble))
foreign import ccall "dynamic" dyn_sin :: FunPtr (CDouble -> CDouble) -> (CDouble -> CDouble)
</pre><pre class="wiki">$ ghc w.hs -o w -fvia-c -O; ./w
0.4400000000000002
(7926335344172077,-54)
0.42593946506599983
0.4259394650659998
5.551115123125783e-17
</pre><p>
optasm:
</p>
<pre class="wiki">{-# LANGUAGE ForeignFunctionInterface #-}
import Control.Monad
import Foreign
import Foreign.C
main :: IO ()
main = do sin_addr <- wrapId sin
doit sin (dyn_sin sin_addr) (encodeFloat 7926335344172077 (-54))
freeHaskellFunPtr sin_addr
doit :: (CDouble -> CDouble) -> (CDouble -> CDouble) -> CDouble -> IO ()
doit f g x = do let fx = f x
gx = g x
when (fx /= gx) $ do print x
print (decodeFloat x)
print fx
print gx
print (decodeFloat fx)
print (decodeFloat gx)
print (fx == gx)
print (decodeFloat fx == decodeFloat gx)
print (fx - gx)
foreign import ccall "wrapper" wrapId :: (CDouble -> CDouble) -> IO (FunPtr (CDouble -> CDouble))
foreign import ccall "dynamic" dyn_sin :: FunPtr (CDouble -> CDouble) -> (CDouble -> CDouble)
</pre><pre class="wiki">$ ghc r.hs -o r -O; ./r
0.4400000000000002
(7926335344172077,-54)
0.4259394650659998
0.4259394650659998
(7673043264614500,-54)
(7673043264614500,-54)
False
True
0.0
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4105#changelog
http://ghc.haskell.org/trac/ghc/ticket/4114
http://ghc.haskell.org/trac/ghc/ticket/4114#4114: Add a flag to remove/delete intermediate files generated by GHCWed, 02 Jun 2010 21:37:46 GMTguest<p>
See for example <a class="ext-link" href="http://stackoverflow.com/questions/1411089/how-to-stop-ghc-from-generating-intermediate-files"><span class="icon"></span>http://stackoverflow.com/questions/1411089/how-to-stop-ghc-from-generating-intermediate-files</a> or
<a class="ext-link" href="http://www.haskell.org/pipermail/xmonad/2010-May/010180.html"><span class="icon"></span>http://www.haskell.org/pipermail/xmonad/2010-May/010180.html</a> /
</p>
<p>
Currently GHC generates *.o and *.hi files for executables, possibly quite a few. They take up space, filenames, and interfere with tab-completion.
</p>
<p>
(And they may be worse than that. I occasionally see users in #xmonad who seem to have subtle compilation issues after upgrades linked to stale .hi and .o files.)
</p>
<p>
There doesn't seem to be any good way to remove the intermediates for a program like Xmonad. They can't be redirected to /dev/null, it's a potential security problem to redirect them to /tmp, and removing them manually is difficult (Xmonad could hardwire in removeFiles of 'xmonad.o' and 'xmonad.hi', but what about the arbitrary user modules in ~/.xmonad/lib? Now one needs to start working with globs or utilities like 'find'...).
</p>
<p>
Of course, GHC knows precisely what's being generated, and could easily remove them. So another flag in the line of -fforce-recompilation seems warranted; perhaps -fforce-no-intermediates?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4114#changelog
http://ghc.haskell.org/trac/ghc/ticket/4121
http://ghc.haskell.org/trac/ghc/ticket/4121#4121: Refactor the plumbing of CafInfo to make it more robustMon, 07 Jun 2010 15:31:17 GMTdterei<p>
While comping GHC Head using the devel1 flavour and ghc-6.12.2 as the bootstrap compiler, I get the following assertion failure:
</p>
<pre class="wiki">"inplace/bin/ghc-stage1" -H64m -O -fasm -package-name base-4.3.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.2.0.0 -package integer-gmp-0.2.0.0 -package rts-1.0 -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XStandaloneDeriving -XPatternGuards -XEmptyDataDecls -XNoImplicitPrelude -XCPP -no-user-package-conf -rtsopts -O -dcore-lint -fno-warn-deprecated-flags -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/base/./Control/Applicative.hs -o libraries/base/dist-install/build/Control/Applicative.o
WARNING: file compiler/simplCore/CSE.lhs line 349 a_aup
WARNING: file compiler/simplCore/CSE.lhs line 349 a_aup
WARNING: file compiler/stgSyn/CoreToStg.lhs line 220
Control.Applicative.$fAlternativeSTM
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 6.13 for i386-unknown-linux):
ASSERT failed! file compiler/stgSyn/CoreToStg.lhs line 187
...blah...
base:Control.Applicative.$fAlternativeSTM{v rk} [gid[DFunId]] =
[] \u srt:SRT:[] []
let {
sat_s1oj{v} [lid] =
[] \r srt:SRT:[] [eta_B1{v} [lid]] retry#{v} [eta_B1{v} [lid]];
} in
base:Control.Applicative.D:Alternative{d rra} [base:Control.Applicative.$fApplicativeSTM{v r2q} [gid[DFunId]]
sat_s1oj{v} [lid]
base:GHC.Conc.orElse1{v re9} [gid]
base:Control.Applicative.$fAlternativeSTM3{v r2n} [gid]
base:Control.Applicative.$fAlternativeSTM1{v r2l} [gid]];
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre><p>
This is on the 32bit MSRC machine by the way. On my own laptop running Ubuntu 10.04 I don't get this (bootstrap compiler is 6.12.1 though).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4121#changelog
http://ghc.haskell.org/trac/ghc/ticket/4140
http://ghc.haskell.org/trac/ghc/ticket/4140#4140: dynHelloWorld(dyn) fails in an unreg buildThu, 17 Jun 2010 21:50:54 GMTigloo<p>
In an unregisterised build, <tt>dynHelloWorld(dyn)</tt> is failing: there is nothing on stdout when output is redirected to a file.
</p>
<p>
It looks like <tt>GHC.TopHandler.cleanUp</tt> is flushing the wrong <tt>stdout</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4140#changelog
http://ghc.haskell.org/trac/ghc/ticket/4176
http://ghc.haskell.org/trac/ghc/ticket/4176#4176: reject unary minus in infix left hand side function bindings that resolve differently as expressionsWed, 07 Jul 2010 09:27:52 GMTmaeder<p>
a program like:
</p>
<pre class="wiki">infix 7 ##
(##) :: Int -> Int -> Int
- 1 ## 0 = 0
_ ## _ = 1
</pre><p>
evaluates (unexpectedly) as
</p>
<pre class="wiki">*Main> - 1 ## 0
-1
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4176#changelog
http://ghc.haskell.org/trac/ghc/ticket/4222
http://ghc.haskell.org/trac/ghc/ticket/4222#4222: Template Haskell lets you reify supposedly-abstract data typesMon, 26 Jul 2010 11:02:46 GMTsimonpj<p>
Serguey Zefirov writes (<a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2010-July/079802.html"><span class="icon"></span>on Haskell cafe</a>) "Data.Map.Map and Data.Set.Set are exported abstractly, without exposing knowledge about their internal structure.
</p>
<p>
I cannot directly create my own class instances for them because of that. But I found that I can write Template Haskell code that could do that - those data types could be reified just fine."
</p>
<p>
Good point. It's not quite clear what a better design should be. Haskell controls data abstraction by whether or not the constructors of the data type are exported. But they might be exported by the module that <em>defined</em> them, but <em>not</em> to "clients" of the data type. So the data type is abstract to some importers but concrete to others.
</p>
<p>
So when should TH let you reify the representation of a data type? Maybe it should let you do so iff
</p>
<ul><li>The data constructors of the data type are in scope (somehow) at the reification site
</li></ul><p>
So, to take an example:
</p>
<pre class="wiki">module Conc( T(..), Blah(..) ) where
data T = T1 | T2 Blah
data Blah = A | B
module Abs( T, Blah ) where
import Conc
module ReifyA where
import Abs
foo = reify ''T
module ReifyC where
import Conc
foo = reify ''T
</pre><p>
So the <tt>reify</tt> in <tt>ReifyC.foo</tt> would "see" the data constructors of <tt>T</tt>, but not the one in <tt>ReifyA</tt>.
</p>
<p>
But this approach raises related questions.
</p>
<ul><li>What if some, but not all, of <tt>T</tt>'s data constructors are in scope?
</li></ul><ul><li>What if the data constructors are all in scope, but some mention a type that is not in scope? For example, suppose type <tt>Blah</tt> is not in scope, but you reify <tt>T</tt>?
</li></ul><ul><li>At the moment, when you reify a data type you get its <tt>Dec</tt>. But if <tt>T</tt> is abstract, what <tt>Dec</tt> can we give it? Just giving it an empty constructor list seems wrong; after all, it might really <em>be</em> a zero-constructor data type. I suspect we may want a richer data type for <tt>Info</tt> (ie what <tt>reify</tt> returns).
</li></ul><p>
All these require design thinking. Does anyone want to lead that debate? Otherwise things will probably stay as they are.
</p>
<p>
I've labelled this as a feature request, although it is a kind of bug, because of this design component.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4222#changelog
http://ghc.haskell.org/trac/ghc/ticket/4281
http://ghc.haskell.org/trac/ghc/ticket/4281#4281: Make impredicativity work properlyWed, 01 Sep 2010 11:44:08 GMTsimonpj<p>
This ticket is a placeholder for work on impredicativity. In fact, with the new typechecker we have most of the story for impredicativity in place, in the style of QML. Still missing are:
</p>
<ul><li>Rigid type signatures
</li><li>Notation for type application
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4281#changelog
http://ghc.haskell.org/trac/ghc/ticket/4288
http://ghc.haskell.org/trac/ghc/ticket/4288#4288: Poor -fspec-constr-count=n warning messagesSat, 04 Sep 2010 13:27:14 GMTigloo<p>
The attached file, compiled with
</p>
<pre class="wiki">ghc -O2 -fspec-constr-count=5 -c q.hs
</pre><p>
gives a number of messages like
</p>
<pre class="wiki">SpecConstr
Function `$j_X1BO{v} [lid]'
has one call pattern, but the limit is 0
Use -fspec-constr-count=n to set the bound
Use -dppr-debug to see specialisations
SpecConstr
Function `$j_X1BR{v} [lid]'
has two call patterns, but the limit is 1
Use -fspec-constr-count=n to set the bound
Use -dppr-debug to see specialisations
</pre><p>
Note that the limit doesn't match the <tt>spec-constr-count</tt> we set.
</p>
<p>
The "limit" given is <tt>sc_count</tt>, but <tt>decreaseSpecCount</tt> changes <tt>sc_count</tt> from its default of <tt>specConstrCount dflags</tt>. However, if this was fixed then we would get even stranger messages like
</p>
<pre class="wiki"> has two call patterns, but the limit is 5
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4288#changelog
http://ghc.haskell.org/trac/ghc/ticket/4296
http://ghc.haskell.org/trac/ghc/ticket/4296#4296: The dreaded SkolemOccurs problemTue, 07 Sep 2010 13:35:20 GMTsimonpj<p>
The "SkolemOccurs" problem is a celebrated difficulty with combining (a) termination and (b) completeness, in this example:
</p>
<pre class="wiki">type instance F [a] = [F a]
f :: (F [a] ~ a) => ...
</pre><p>
Currently we err on the side of completeness, and lose termination:
</p>
<pre class="wiki">Simple20.hs:9:1:
Context reduction stack overflow; size = 21
Use -fcontext-stack=N to increase stack size to N
co :: F [F (F (F (F (F (F (F (F (F (F a)))))))))]
~
F (F (F (F (F (F (F (F (F (F a)))))))))
co :: F (F (F (F (F (F (F (F (F a))))))))
~
[F (F (F (F (F (F (F (F (F (F a)))))))))]
co :: F [F (F (F (F (F (F (F (F (F a))))))))]
~
F (F (F (F (F (F (F (F (F a))))))))
co :: F (F (F (F (F (F (F (F a)))))))
~
[F (F (F (F (F (F (F (F (F a))))))))]
co :: F [F (F (F (F (F (F (F (F a)))))))]
~
F (F (F (F (F (F (F (F a)))))))
co :: F (F (F (F (F (F (F a))))))
~
[F (F (F (F (F (F (F (F a)))))))]
co :: F [F (F (F (F (F (F (F a))))))] ~ F (F (F (F (F (F (F a))))))
co :: F (F (F (F (F (F a))))) ~ [F (F (F (F (F (F (F a))))))]
co :: F [F (F (F (F (F (F a)))))] ~ F (F (F (F (F (F a)))))
co :: F (F (F (F (F a)))) ~ [F (F (F (F (F (F a)))))]
co :: F [F (F (F (F (F a))))] ~ F (F (F (F (F a))))
co :: F (F (F (F a))) ~ [F (F (F (F (F a))))]
co :: F [F (F (F (F a)))] ~ F (F (F (F a)))
co :: F (F (F a)) ~ [F (F (F (F a)))]
co :: F [F (F (F a))] ~ F (F (F a))
co :: F (F a) ~ [F (F (F a))]
co :: F [F (F a)] ~ F (F a)
co :: F a ~ [F (F a)]
co :: F [F a] ~ F a
co :: a ~ [F a]
co :: F [a] ~ a
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4296#changelog
http://ghc.haskell.org/trac/ghc/ticket/4301
http://ghc.haskell.org/trac/ghc/ticket/4301#4301: Optimisations give bad core for foldl' (flip seq) ()Fri, 10 Sep 2010 18:34:41 GMTdaniel.is.fischer<p>
I'm not sure whether it's one freak case or a symptom of a problem that occurs more often. Compiled with optimisations, the code
</p>
<pre class="wiki">foo :: [a] -> ()
foo = foldl' (flip seq) ()
</pre><p>
produces the core
</p>
<pre class="wiki">Rec {
FSeq.foo1 :: forall a_af0. [a_af0] -> (##)
GblId
[Arity 1
NoCafRefs
Str: DmdType S]
FSeq.foo1 =
\ (@ a_af0) (w_sg9 :: [a_af0]) ->
case case w_sg9 of _ {
[] -> GHC.Unit.();
: x_afz xs_afA ->
case x_afz of _ { __DEFAULT ->
case FSeq.foo1 @ a_af0 xs_afA of _ { (# #) -> GHC.Unit.() }
}
}
of _ { () ->
GHC.Prim.(##)
}
end Rec }
</pre><p>
for the worker (ghc-6.12.3, similar core from HEAD). Due to the boxing and unboxing between (##) and (), there's a case on the recursive call, hence it produces a stack overflow on long enough lists.
</p>
<p>
The problem was reported in <a class="ext-link" href="http://www.haskell.org/pipermail/beginners/2010-September/005287.html"><span class="icon"></span>http://www.haskell.org/pipermail/beginners/2010-September/005287.html</a>, my attempt at understanding it here: <a class="ext-link" href="http://www.haskell.org/pipermail/beginners/2010-September/005293.html"><span class="icon"></span>http://www.haskell.org/pipermail/beginners/2010-September/005293.html</a>.
</p>
<p>
So far, I've only managed to produce it for the very special combination of foldl' (flip seq) and a single (non-bottom) value datatype; any other function to be folded or a multiple value type produce a tail-recursive two-argument worker.
</p>
<p>
Nevertheless, on the off chance that it's a symptom of a real problem, I'm reporting it.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4301#changelog
http://ghc.haskell.org/trac/ghc/ticket/4329
http://ghc.haskell.org/trac/ghc/ticket/4329#4329: GHC.Conc modifyTVar primitiveTue, 21 Sep 2010 20:18:14 GMTdmbarbour<p>
I would like modifyTVar as a 'write-only' primitive supported by GHC's STM.
</p>
<p>
The semantic definition is:
</p>
<blockquote class="citation">
<p>
modifyTVar :: TVar a -> (a -> a) -> STM ()
modifyTVar v f = readTVar v >>= writeTVar v . f
</p>
</blockquote>
<p>
However, explicitly reading then writing the TVar introduces unnecessary interference between transactions. The value held by the TVar does not affect the behavior of the transaction. modifyTVar should not interfere with other transactions that only writeTVar or modifyTVar.
</p>
<p>
Even if a non-interfering implementation isn't feasible due to the underlying implementation of GHC's STM, providing the function would provide a point for a transparent upgrade in the future.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4329#changelog
http://ghc.haskell.org/trac/ghc/ticket/4428
http://ghc.haskell.org/trac/ghc/ticket/4428#4428: Local functions lose their unfoldingsSat, 23 Oct 2010 00:12:56 GMTrl<p>
I'm attaching 2 modules, both should be compiled with -O2. Let's look at the inteface of <tt>Foo</tt>:
</p>
<pre class="wiki"> foo :: (GHC.Types.Int, GHC.Types.Int)
-> [GHC.Types.Int]
-> [GHC.Types.Int]
{- Arity: 2, Strictness: U(U(L)U(L))L, Inline: INLINE (sat-args=2),
Unfolding: InlineRule (2, False, False)
(\ ds :: (GHC.Types.Int, GHC.Types.Int) xs :: [GHC.Types.Int] ->
case @ [GHC.Types.Int] ds of wild { (i, n) ->
let {
step :: forall t.
([t], GHC.Types.Int, GHC.Types.Int)
-> Data.Maybe.Maybe (([t], GHC.Types.Int, GHC.Types.Int), t)
{- Inline: INLINE[0] (sat-args=1) -}
= ...
</pre><p>
Note how <tt>step</tt>, which is local to <tt>foo</tt>, has an <tt>INLINE</tt> pragma but no unfolding. Now, let's look at <tt>Bar</tt>. For some reason, GHC only inlines <tt>foo</tt> into <tt>bar</tt> in phase 1. This is probably unrelated but still surprising. The main problem, though, is that <tt>step</tt>, not having an unfolding, doesn't get inlined at all despite the <tt>INLINE</tt> pragma.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4428#changelog
http://ghc.haskell.org/trac/ghc/ticket/4453
http://ghc.haskell.org/trac/ghc/ticket/4453#4453: Allow specifying .hi files of imports on command line in batch modeFri, 29 Oct 2010 14:31:29 GMTduncan<p>
It is useful for a build agent (e.g. cabal, or makefile) to have full control over the search path. Reasons you might want to do this are below.
</p>
<p>
The way a build agent can do this is to instruct ghc not to do any searching at all, using the flag <tt>-i</tt> which sets the search path to empty. Then the build agent has to supply ghc with all the <tt>.hs</tt> files that are needed, e.g.:
</p>
<pre class="wiki">ghc --make -i Foo.hs Bar.hs
</pre><p>
(any imports outside of these modules, or the package modules will fail)
</p>
<p>
This no-search scheme works in <tt>--make</tt> mode but not in batch mode. For that we need to be able to say:
</p>
<pre class="wiki">ghc -i -c Foo.hs
ghc -i -c Bar.hs Foo.hi
</pre><p>
That is, we need to be able to specify the .hi files of imported modules on the command line.
</p>
<p>
A build agent may want to do this so that it is insulated from the particular choices of ghc's search path semantics and/or have different choices. For example, ghc prefers modules in local .hs/.hi files to package modules while the build agent may want the reverse in some circumstances.
</p>
<p>
Apart from search path policy, it makes sense for a build agent to take this approach simply for correctness and simplicity. A correct build agent must track dependencies absolutely precisely, so it has to know which specific .hi files ghc will pick anyway. It is simpler for the build agent to tell ghc those .hi files rather than trying to precisely arrange things to match ghc's search behaviour.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4453#changelog
http://ghc.haskell.org/trac/ghc/ticket/4466
http://ghc.haskell.org/trac/ghc/ticket/4466#4466: Add extension for type applicationTue, 02 Nov 2010 19:48:41 GMTigloo<p>
In
<a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2010-October/014761.html"><span class="icon"></span>http://www.haskell.org/pipermail/libraries/2010-October/014761.html</a>
we discussed adding an extension for explicit type application.
</p>
<p>
The main stumbling block is syntax.
</p>
<p>
For example, we would like to be able to write something to the effect of
</p>
<pre class="wiki">(Just @ Char) 'a'
</pre><p>
and also to be able to pattern match types, e.g.
</p>
<pre class="wiki">f ((Just @ t) x) = (Right @ String @ t) x
</pre><p>
For a more useful example:
</p>
<pre class="wiki">data T where
MkT :: forall a. a -> (a -> Int) -> T
f (MkT @ a x g) = g (x::a)
</pre><p>
Possible suggested syntaxes to make something of type
</p>
<pre class="wiki">Maybe (forall a. a->a)
</pre><p>
were:
</p>
<pre class="wiki">Just @ (forall a. a->a) id (@ has another meaning in patterns)
Just[forall a. a->a] id (pvs, opal, HasCASL with paramterized modules; conflicts with Haskell list syntax)
Just {forall a. a->a} id (Agda)
#Just (forall a. a->a) id
@Just (forall a. a->a) id (coq)
</pre><p>
In the last 2 cases we would presumably have something like
</p>
<pre class="wiki">Just :: forall a . a -> Maybe a
Just :: Char -> Maybe Char
#Just :: /\ a . a -> Maybe a
#Just Char :: Char -> Maybe Char
</pre><p>
and similarly
</p>
<pre class="wiki">#map :: /\ a b . (a -> b) -> [a] -> [b]
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4466#changelog
http://ghc.haskell.org/trac/ghc/ticket/4471
http://ghc.haskell.org/trac/ghc/ticket/4471#4471: Incorrect Unicode output on Windows ConsoleThu, 04 Nov 2010 18:31:44 GMTsankeld<p>
To reproduce,
</p>
<ul><li>start a windows console
</li><li>Change the console's font to a ttf unicode font, like "Lucida Console".
</li><li>Type "chcp 65001" to set it to the UTF-8 code page.
</li></ul><p>
test.hs
</p>
<pre class="wiki">main = putStrLn "∷⇒∀→←⋯⊢"
</pre><p>
Output to the console is garbled. <tt>runghc test.hs</tt>:
</p>
<pre class="wiki">∷⇒∀→←⋯⊢
→←⋯⊢
⋯⊢
∷⇒∀→←⋯⊢→←⋯⊢←⋯⊢⋯⊢⊢⊢⊢<stdout>: hFlush: permission denied (Permission denied)
</pre><p>
Piping works correctly. <tt>runghc test.hs > output && type output</tt>:
</p>
<pre class="wiki">∷⇒∀→←⋯⊢
</pre><p>
ghci fails. <tt>ghci test.hs</tt>
</p>
<pre class="wiki">GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
[1 of 1] Compiling Main ( test.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
∷*** Exception: <stdout>: hPutChar: permission denied (Permission denied)
*Main>
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4471#changelog
http://ghc.haskell.org/trac/ghc/ticket/4505
http://ghc.haskell.org/trac/ghc/ticket/4505#4505: Segmentation fault on long input (list of pairs)Wed, 17 Nov 2010 14:58:37 GMTcathper<p>
When compiling LongList.hs with
</p>
<pre class="wiki">ghc --make LongList.hs
</pre><p>
then running the output gives a segfault:
</p>
<pre class="wiki">$ ./LongList
8595
Segmentation fault
</pre><p>
It also segfaults with ghc 6.12.1 (without printing 8595) and with ghc 6.12.3.
</p>
<p>
On ghc 6.12.3 running on Mac OS 10.5, no segfault is seen. (I haven't tried much longer input, since it already eats up approx. 1.2 GB of RAM.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4505#changelog
http://ghc.haskell.org/trac/ghc/ticket/4800
http://ghc.haskell.org/trac/ghc/ticket/4800#4800: Memory Leak when Compiling qtHaskellMon, 29 Nov 2010 08:48:08 GMTgidyn<p>
I get an out-of-memory error about two thirds of the way through building qtHaskell (latest version, 1.1.4). If I start again, the remaining modules are compiled successfully, although GHC's memory usage creeps up to about 1.5Gb by the time it's finished.
</p>
<p>
This is on Win7 x64 with 4Gb RAM.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4800#changelog
http://ghc.haskell.org/trac/ghc/ticket/4806
http://ghc.haskell.org/trac/ghc/ticket/4806#4806: Make error message more user friendly when module is not found because package is unusableTue, 30 Nov 2010 07:33:26 GMTmitar<p>
Make error message more user friendly when module is not found because package is unusable. Currently it just reports that module is missing (the same as it even would not be installed) but then checking with <tt>ghc-pkg find-module</tt> shows package correctly. Chasing '-v' output around can then show you this but it would be easier that you would immediately get a helpful message.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4806#changelog
http://ghc.haskell.org/trac/ghc/ticket/4815
http://ghc.haskell.org/trac/ghc/ticket/4815#4815: Instance constraints should be used when deriving on associated data typesFri, 03 Dec 2010 15:34:23 GMTbatterseapower<p>
Consider this program:
</p>
<pre class="wiki">{-# LANGUAGE TypeFamilies, FlexibleContexts #-}
class Eq (Associated a) => Foo a where
data Associated a
instance Foo a => Foo (Maybe a) where
data Associated (Maybe a) = AssociatedMaybe (Associated a)
deriving (Eq)
</pre><p>
This does not compile, giving this error message:
</p>
<pre class="wiki">
/Users/mbolingbroke/Junk/Repro.hs:9:40:
No instance for (Eq (Associated a))
arising from the 'deriving' clause of a data type declaration
at /Users/mbolingbroke/Junk/Repro.hs:9:40-41
Possible fix:
add an instance declaration for (Eq (Associated a))
or use a standalone 'deriving instance' declaration instead,
so you can specify the instance context yourself
When deriving the instance for (Eq (Associated (Maybe a)))
</pre><p>
However, this is surprising because I clearly state that a is Foo, and hence (Associated a) has an Eq instance by the superclass constraint on Foo.
</p>
<p>
If I point this out explicitly using standalone deriving it works:
</p>
<pre class="wiki">{-# LANGUAGE TypeFamilies, FlexibleContexts #-}
{-# LANGUAGE StandaloneDeriving, FlexibleInstances #-}
class Eq (Associated a) => Foo a where
data Associated a
instance Foo a => Foo (Maybe a) where
data Associated (Maybe a) = AssociatedMaybe (Associated a)
-- deriving (Eq)
deriving instance Foo a => Eq (Associated (Maybe a))
</pre><p>
So I think the default behaviour for "deriving" on an associated data family should be to include the constraints from the enclosing instance. For now the workaround is just to use standalone deriving.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4815#changelog
http://ghc.haskell.org/trac/ghc/ticket/4823
http://ghc.haskell.org/trac/ghc/ticket/4823#4823: Loop strength reduction for array indexingTue, 07 Dec 2010 16:46:09 GMTtibbe<p>
Indexing into a <tt>ByteArray#</tt> in a loop is currently more expensive than working on a <tt>ForeignPtr</tt> due to lack of strength reduction. Pointer arithmetic is cheaper than using base + offset indexing. We could convert indexing into pointer arithmetic if it weren't for the GC being able to move objects around.
</p>
<p>
Tom Rodriguez had the following to say about Java HotSpot and loop strength reduction:
</p>
<blockquote class="citation">
<p>
"The server compiler doesn't do explicit loop strength reduction though it can get a bit of it as a result of other transformations loop invariant code motion. I've played a bit with doing it more explicitly but had some difficulty getting benefit from it. The resulting pointers are handled by the notion of derived pointers. These are interior pointers that are tracked along with their base pointers. At the beginning of GC the offset from the base of the derived pointer is saved and the pointer is converted to the base and after GC the offset is added back in. That part all happens automatically. Searching for DerivedPointer will lead you to the relevant code."
</p>
</blockquote>
<p>
Perhaps it's an idea we could try?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4823#changelog
http://ghc.haskell.org/trac/ghc/ticket/4833
http://ghc.haskell.org/trac/ghc/ticket/4833#4833: Finding the right loop breakerFri, 10 Dec 2010 15:11:35 GMTsimonpj<p>
This ticket reports a DPH-related optimisation problem.
</p>
<p>
Two files are attached. <tt>Repr.hs</tt> defines the type families and classes:
</p>
<ul><li><tt>PR</tt> is the class which defines basic operations (<tt>rep</tt> for replication and <tt>idx</tt> for indexing). It has only a fixed number of instance.
</li></ul><ul><li><tt>PRepr a</tt> is the representation type of <tt>a</tt>. It must be an instance of <tt>PR</tt>
</li></ul><ul><li><tt>PA</tt> is the class which defines conversions to and from representation types; all vectorised user-defined types are instances of <tt>PA</tt>
</li></ul><ul><li><tt>repPA</tt> is an example of a generic operation: we convert the argument to its representation type, perform the PR operation on it and convert it back
</li></ul><ul><li><tt>Wrap</tt> is a representation type which simply wraps a <tt>PA</tt> type; <tt>instance PA (a,b)</tt> is an example of how it is used
</li></ul><p>
In <tt>Dict.hs</tt>, we define the recursive type <tt>S</tt> and its <tt>PA</tt> instance which basically looks exactly like what the vectoriser would generate. Note that we don't have to define a <tt>PR</tt> instance which is the whole point. This all works but if we look at the Core, we see that the <tt>PA</tt> dictionary of <tt>S</tt> is recursive:
</p>
<pre class="wiki">Dict.$fPAS =
Repr.D:PA
@ Dict.S
($dPR_ad1 `cast` ...)
$ctoPRepr_acn
$cfromPRepr_acq
$ctoArrPRepr_act
$cfromArrPRepr_acG
$dPR_ad5 :: Repr.PR (Repr.Wrap Dict.S)
$dPR_ad5 = Repr.$fPRWrap @ Dict.S Dict.$fPAS
$dPR_ad1 [Occ=LoopBreaker]
:: Repr.PR (GHC.Types.Double, Repr.Wrap Dict.S)
$dPR_ad1 =
Repr.$fPR(,)
@ GHC.Types.Double @ (Repr.Wrap Dict.S) Repr.$fPRDouble $dPR_ad5
</pre><p>
Note that <tt>$dPR_ad1</tt> is a loop breaker. This means that foo in Dict.hs can't be optimised properly:
</p>
<pre class="wiki">Dict.foo =
\ (s_ac0 :: Dict.S) (n_ac1 :: GHC.Types.Int) ->
case (Repr.rep
@ (Repr.PRepr Dict.S)
($dPR_ad1 `cast` ...)
n_ac1
(case s_ac0 of _ { Dict.S x_ac2 y_ac3 ->
(x_ac2,
y_ac3 `cast` ...) `cast` ...
})) `cast` ...
of _ { Repr.P2 xs_ac8 ds_ddJ ->
case ds_ddJ `cast` ...
of _ { Repr.PWrap ys_ac9 ->
(Dict.PS xs_ac8 ys_ac9) `cast` ...
}
}
</pre><p>
The <tt>(rep $dPR_ad1)</tt> call can't be resolved even though we know what it is. This is actually due to an unfortunate choice of loop breaker: $dPR_ad5 would work much better here. In general, we would perhaps like to say that we always want to pick PR (Wrap t) dictionaries as loop breakers in such cases.
</p>
<p>
Although what we'd really like is for foo itself to become a recursive function which can't happen with the current set up. I might have an idea how to do this but I need to think a bit more about it.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4833#changelog
http://ghc.haskell.org/trac/ghc/ticket/4836
http://ghc.haskell.org/trac/ghc/ticket/4836#4836: literate markdown not handled correctly by unlitSun, 12 Dec 2010 19:22:52 GMTguest<p>
This simple program in literate haskell, using markdown in the comments gives unlit problems:
</p>
<pre class="wiki">### Ok so lets try this again.
### A page that loads and compiles:
> myfact 0 = 1
> myfact n = n * n-1
Lets see if it works!
</pre><p>
If I run unlit and collect the output I can see where it went wrong:
</p>
<pre class="wiki">$ ~/lib/ghc-7.0.1/unlit Main.lhs Main.lpp
$ cat Main.lpp
### Ok so lets try this again.
### A page that loads and compiles:
myfact 0 = 1
myfact n = n * n-1
</pre><p>
When I look through the source code of unlit.c I think the place to check for this would be here:
</p>
<pre class="wiki"> if ( c == '#' ) {
if ( ignore_shebang ) {
c1 = egetc(istream);
if ( c1 == '!' ) {
while (c=egetc(istream), !isLineTerm(c)) ;
return SHEBANG;
}
myputc(c, ostream);
c=c1;
}
if ( leavecpp ) {
myputc(c, ostream);
while (c=egetc(istream), !isLineTerm(c))
myputc(c,ostream);
myputc('\n',ostream);
return HASH;
}
}
</pre><p>
It seems that cabal has a similar unlit function:
<a href="http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal-1.10.0.0/src/Distribution-Simple-PreProcess-Unlit.html#unlit">http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal-1.10.0.0/src/Distribution-Simple-PreProcess-Unlit.html#unlit</a>
</p>
<p>
I haven't tested it but, I think the cabal version would handle this case correctly (or be easier to fix than a C program from 1990). Would it be possible/wise/feasible to extract the cabal version and make it a permanent replacement for the current unlit.c code?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4836#changelog
http://ghc.haskell.org/trac/ghc/ticket/4896
http://ghc.haskell.org/trac/ghc/ticket/4896#4896: Deriving Data does not work for attached codeMon, 17 Jan 2011 12:14:11 GMTmitar<p>
I get the following error when I try to derive <tt>Data</tt> for the attached code:
</p>
<pre class="wiki">Main.hs:17:66:
Couldn't match expected type `Bar (D a b)'
with actual type `t' a1 b1'
Expected type: Maybe (c (Bar (D a b)))
Actual type: Maybe (c (t' a1 b1))
In the expression: gcast2 f
In an equation for `dataCast2': dataCast2 f = gcast2 f
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4896#changelog