GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=!closed&owner=benl&desc=1&order=priority
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?status=!closed&owner=benl&desc=1&order=priority
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/3782
http://ghc.haskell.org/trac/ghc/ticket/3782#3782: Data Parallel "Impossible happened" compiler errorWed, 23 Dec 2009 21:41:17 GMTguest<p>
When I attempted to compile my vectorized code , I got the following message:
</p>
<pre class="wiki">ghc -c -Odph -fcpr-off -fdph-seq newprop.hs
ghc: panic! (the 'impossible' happened)
(GHC version 6.12.1 for i386-apple-darwin):
sumTyCon 11
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3782#changelog
http://ghc.haskell.org/trac/ghc/ticket/3903
http://ghc.haskell.org/trac/ghc/ticket/3903#3903: DPH bad sliceP causes RTS panic "allocGroup: requested zero blocks"Mon, 01 Mar 2010 08:47:36 GMTbenl<pre class="wiki">$ ghci -XPArr
...
Prelude> :m GHC.PArr
Prelude GHC.PArr> sliceP 10 10 [::]
<interactive>: internal error: allocGroup: requested zero blocks
(GHC version 6.12.1 for i386_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort trap
</pre><p>
<tt>sliceP 10 10 [::]</tt> is bogus. This should have been picked up in the libraries before hitting the RTS assertion.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3903#changelog
http://ghc.haskell.org/trac/ghc/ticket/4081
http://ghc.haskell.org/trac/ghc/ticket/4081#4081: Strict constructor fields inspected in loopWed, 19 May 2010 12:21:26 GMTrl<p>
Here is a small example to illustrate the problem:
</p>
<pre class="wiki">module T where
data S a b = S !a !b
class C a where
make :: a -> S a a
instance C Int where
{-# NOINLINE make #-}
make n = S n n
foo :: (C a, Num a) => a -> Int -> a
{-# INLINE foo #-}
foo x k = k `seq` m `seq` go k 0
where
S m n = make x
go 0 i = i
go k i = go (k-1) (i + m)
</pre><pre class="wiki">module U where
import T
bar :: Int -> Int -> Int
bar s k = foo s k + 1
</pre><p>
Relying on LiberateCase seems to be the only way to unbox <tt>m</tt> outside of the loop in <tt>bar</tt>. The seq in <tt>foo</tt> doesn't help because it gets eliminated immediately.
</p>
<p>
GHC does have enough information to do this:
</p>
<pre class="wiki">U.bar =
\ (s_aaw [Dmd=Just S(A)] :: GHC.Types.Int)
(k_aax [Dmd=Just U(L)] :: GHC.Types.Int) ->
case k_aax
of k1_ajh [Dmd=Just U(L)] { GHC.Types.I# ipv_ajj [Dmd=Just A] ->
case T.$fCInt_$cmake s_aaw of _ { T.S m_ajy [Dmd=Just U(T)] _ ->
...
</pre><p>
Note the demand on <tt>m</tt>. If it was an argument instead of a local binding, it would be unboxed by w/w.
</p>
<p>
Also, the seq does help if we use lazy pairs instead of strict ones.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4081#changelog
http://ghc.haskell.org/trac/ghc/ticket/4438
http://ghc.haskell.org/trac/ghc/ticket/4438#4438: Rename and register the "PArr" language extension when it is judged to be readyMon, 25 Oct 2010 18:47:06 GMTduncan<p>
Language extensions used in distributed packages need to be registered in <tt>Language.Haskell.Extension</tt> (which currently lives in the Cabal lib).
</p>
<p>
When the DPH hackers think that the <tt>PArr</tt> extension is ready for public consumption then they should register it. It will need to be renamed to something more descriptive, see the <tt>Language.Haskell.Extension</tt> module for examples. The style is to use full words. Perhaps <tt>ParallelArrays</tt> would be an appropriate choice.
</p>
<p>
Currently the <tt>PArr</tt> extension is the only GHC extension that is deliberately not registered (there are others that are accidentally not registered). It is listed as an exception in the testsuite test that checks for GHC extensions that are accidentally not registered. See ticket <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4437" title="bug: unregistered language extensions (closed: fixed)">#4437</a>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4438#changelog
http://ghc.haskell.org/trac/ghc/ticket/5807
http://ghc.haskell.org/trac/ghc/ticket/5807#5807: DPH library functions don't work without -fvectorise.Mon, 23 Jan 2012 00:58:29 GMTbenl<p>
Mukesh Tiwari reports:
</p>
<pre class="wiki">ghci>import Data.Array.Parallel
ghci>import Data.Array.Parallel.PArray
ghci>let u = Data.Array.Parallel.PArray.fromList [ 1 .. 10 ]
ghci>:t u
u :: PArray Double
ghci>u
fromList<PArray> [1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0]
ghci>let v = Data.Array.Parallel.fromPArrayP u
ghci>:t v
v :: [:Double:]
ghci>lengthP v
0
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5807#changelog
http://ghc.haskell.org/trac/ghc/ticket/6004
http://ghc.haskell.org/trac/ghc/ticket/6004#6004: dph-lifted-vseg package doesn't provide Data.Array.Parallel.Prelude.Float moduleFri, 13 Apr 2012 18:08:15 GMTshelarcy<p>
dph-lifted-copy package and old dph-par package provide Data.Array.Parallel.Prelude.Float module.
</p>
<ul><li><a class="ext-link" href="http://hackage.haskell.org/package/dph-lifted-copy"><span class="icon"></span>http://hackage.haskell.org/package/dph-lifted-copy</a>
</li><li><a class="ext-link" href="http://hackage.haskell.org/package/dph-par"><span class="icon"></span>http://hackage.haskell.org/package/dph-par</a>
</li></ul><p>
But dph-lifted-vseg package doesn't provide Data.Array.Parallel.Prelude.Float module, now.
</p>
<ul><li><a class="ext-link" href="http://hackage.haskell.org/package/dph-lifted-vseg-0.6.1.2"><span class="icon"></span>http://hackage.haskell.org/package/dph-lifted-vseg-0.6.1.2</a>
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/6004#changelog
http://ghc.haskell.org/trac/ghc/ticket/7063
http://ghc.haskell.org/trac/ghc/ticket/7063#7063: Register allocators can't handle non-uniform register setsMon, 09 Jul 2012 12:51:42 GMTsimonmar<p>
Neither the linear scan register allocator nor the graph-colouring allocator can properly handle the fact that some registers on x86 have 8 and 16-bit versions and some don't. We got away with this until now because the only free registers on x86 were <tt>%eax</tt>, <tt>%ecx</tt> and <tt>%edx</tt>, but now we can also treat <tt>%esi</tt> as free when it isn't being used for R1 (see <a class="changeset" href="http://ghc.haskell.org/trac/ghc/changeset/f857f0741515b9ebf186beb38fe64448de355817/ghc" title="Allow the register allocator access to argument regs (R1.., F1.., etc.)
...">f857f0741515b9ebf186beb38fe64448de355817</a>). However, <tt>%esi</tt> doesn't have an 8-bit version, so we cannot treat it as allocatable because the register allocator will try to use it when an 8-bit register is needed (see <a class="changeset" href="http://ghc.haskell.org/trac/ghc/changeset/105754792adac0802a9a59b0df188b58fb53503f/ghc" title="Don't re-allocate %esi on x86.
Recent changes have freed up %esi for ...">105754792adac0802a9a59b0df188b58fb53503f</a>).
</p>
<p>
LLVM doesn't have this problem, so one workaround is to compile with <tt>-fllvm</tt> to get the extra register(s) on x86.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7063#changelog
http://ghc.haskell.org/trac/ghc/ticket/7098
http://ghc.haskell.org/trac/ghc/ticket/7098#7098: GHC 7.4.1 reports an internal error and core dumps while using DPHThu, 26 Jul 2012 03:40:52 GMTPrasanna<p>
While compiling a DPH program I got the following error,
</p>
<pre class="wiki">Main: internal error: allocGroup: requested zero blocks
(GHC version 7.4.1 for i386_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
</pre><p>
I have attached the code files that I was using.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7098#changelog
http://ghc.haskell.org/trac/ghc/ticket/7330
http://ghc.haskell.org/trac/ghc/ticket/7330#7330: Data Parallel Haskell (DPH) isn't usable yet.Mon, 15 Oct 2012 03:20:53 GMTbenl<p>
This is a place holder ticket for people that try to use DPH and find problems or missing features. DPH is still deeply experimental, and we don't expect you to be able to do anything useful with it yet.
</p>
<p>
However, it may work well enough to compile and run programs, depending on your particular example. The compiled executables are likely to work, but they will be very slow (like 10 - 100x slower than they should be). If you'd like to try DPH out anyway then feel free to give it a shot. Further questions and comments should be directed to benl@…. No need to open a ticket here in the GHC trac.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7330#changelog