August 2018 - ghc-tickets

[GHC] #13965: COMPLETE sets nerf redundant pattern-match warnings
by GHC 10 Sep '18

10 Sep '18

#13965: COMPLETE sets nerf redundant pattern-match warnings -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, | PatternMatchWarnings | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I give redundant patterns for a datatype with a `COMPLETE` set, then GHC doesn't warn me at all. Here's an example: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} module Bug (Boolean(F, TooGoodToBeTrue), catchAll) where data Boolean = F | T deriving Eq pattern TooGoodToBeTrue :: Boolean pattern TooGoodToBeTrue <- ((== T) -> True) where TooGoodToBeTrue = T {-# COMPLETE F, TooGoodToBeTrue #-} catchAll :: Boolean -> Int catchAll F = 0 catchAll TooGoodToBeTrue = 1 catchAll F = 2 }}} GHC thinks this is fine and dandy: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs -Wall GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, 1 module loaded. }}} This problem also persists across modules: {{{#!hs module Foo where import Bug catchAll2 :: Boolean -> Int catchAll2 F = 0 catchAll2 TooGoodToBeTrue = 1 catchAll2 F = 2 }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Foo.hs -Wall GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 2] Compiling Bug ( Bug.hs, interpreted ) [2 of 2] Compiling Foo ( Foo.hs, interpreted ) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13965> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14912: UnsafeReenter test fails with threaded1 and threaded2
by GHC 10 Sep '18

10 Sep '18

#14912: UnsafeReenter test fails with threaded1 and threaded2 --------------------------------------+--------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.5 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- {{{ /tmp/ghctest-n4fi8zlk/test spaces/./ffi/should_fail/UnsafeReenter.run UnsafeReenter [bad exit code] (threaded1) /tmp/ghctest-n4fi8zlk/test spaces/./ffi/should_fail/UnsafeReenter.run UnsafeReenter [bad exit code] (threaded2) }}} It's a quite simple program: {{{#!hs {-# LANGUAGE ForeignFunctionInterface #-} -- | Test that unsafe FFI calls crash the RTS if they attempt to re-enter -- Haskell-land module Main where import Foreign foreign import ccall "wrapper" wrap_f :: IO () -> IO (FunPtr (IO ())) foreign import ccall unsafe hello :: FunPtr (IO ()) -> IO () f :: IO () f = putStrLn "Back in Haskell" main :: IO () main = do putStrLn "In Haskell" wrap_f f >>= hello putStrLn "Finished" }}} This just seem to hang (until timeout) with the `threaded1` and `threaded2` ways, instead of erroring out with: {{{ UnsafeReenter: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? }}} which is the expected behaviour. I'll mark the test broken for those 2 ways in an upcoming patch, but this probably deserves a new ticket, so here it is. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14912> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12578: Update links to SPJ’s papers
by GHC 09 Sep '18

09 Sep '18

#12578: Update links to SPJ’s papers -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems that Simon’s homepage got restructured, and a lot of links in the documentation and the code comments are not valid any more. At least these need to be looked at: {{{ $ git grep 'people/simonpj' compiler/types/FamInstEnv.hs:http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/axioms-extended.pdf compiler/types/Unify.hs:[1]: http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/axioms-extended.pdf docs/core-spec/core-spec.mng:phantom equality includes all types. See \url{http://ghc.haskell.org/trac/ghc/wiki/Roles} and \url{http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/coercible.pdf} docs/users_guide/glasgow_exts.rst:paper <http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/>`__. docs/users_guide/glasgow_exts.rst:cloud <http://research.microsoft.com/en- us/um/people/simonpj/papers/parallel/remote.pdf>`__, docs/users_guide/using-optimisation.rst: multiprocessor <http://research.microsoft.com/en- us/um/people/simonpj/papers/parallel/>`__. docs/users_guide/using-optimisation.rst: (ICFP'96) <http://research.microsoft.com/en- us/um/people/simonpj/papers/float.ps.gz>`__. docs/users_guide/using-optimisation.rst: (ICFP'96) <http://research.microsoft.com/en- us/um/people/simonpj/papers/float.ps.gz>`__. docs/users_guide/using-optimisation.rst: programs <http://research.microsoft.com/en-us/um/people/simonpj/papers/spec- constr/index.htm>`__. docs/users_guide/using-optimisation.rst: thesis <http://research.microsoft.com/en-us/um/people/simonpj/papers/santos- thesis.ps.gz>`__ docs/users_guide/using-optimisation.rst: analyser <http://research.microsoft.com/en-us/um/people/simonpj/papers/simple- strictnes-analyser.ps.gz>`__, libraries/base/GHC/Arr.hs:-- http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/coercible.pdf libraries/base/GHC/Base.hs:-- http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/coercible.pdf testsuite/tests/dependent/should_compile/all.T:# http://research.microsoft.com/en-us/um/people/simonpj/papers/haskell- dynamic/ $ git grep '~simonpj' compiler/coreSyn/CoreSyn.hs:-- GHC uses System FC <http://research.microsoft.com/~simonpj/papers/ext-f/> for this purpose, docs/users_guide/bugs.rst: inliner <http://research.microsoft.com/~simonpj/Papers/inlining/>`__. docs/users_guide/glasgow_exts.rst: Languages <http://research.microsoft.com/~simonpj/Papers/slpj-book-1987/>`__. docs/users_guide/glasgow_exts.rst:"group by" <http://research.microsoft.com/~simonpj/papers/list-comp>`__, docs/users_guide/glasgow_exts.rst:space <http://research.microsoft.com/~simonpj/Papers/type-class-design- space/>`__ docs/users_guide/glasgow_exts.rst:papers <http://research.microsoft.com/~simonpj/papers/constraints/index.htm>`__ docs/users_guide/glasgow_exts.rst:Haskell <http://research.microsoft.com/~simonpj/papers/meta-haskell/>`__" docs/users_guide/glasgow_exts.rst:2 <http://research.microsoft.com/~simonpj/papers/meta-haskell/notes2.ps>`__. libraries/base/Control/Concurrent/MVar.hs:-- <http://research.microsoft.com/~simonpj/papers/concurrent-haskell.ps.gz "Concurrent Haskell"> libraries/base/GHC/Conc/Sync.hs:(<http://research.microsoft.com/~simonpj/Papers /asynch-exns.htm>). }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12578> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14330: Sparks are not started promptly
by GHC 08 Sep '18

08 Sep '18

#14330: Sparks are not started promptly -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: sparks | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This was a question on StackOverflow. With some prompting from Yuras, I've decided to open this as an issue. Here is the original question (which has been satisfactorily answered): https://stackoverflow.com/questions/46586941/why-are-ghc-sparks- fizzling/46603680?noredirect=1#comment80163830_46603680 Here is a more narrowly tailored version of the code I have posted there: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# OPTIONS_GHC -O2 -Wall -threaded -fforce-recomp #-} import Criterion.Main import Control.Parallel.Strategies (runEval,rpar,rseq) import qualified Data.Vector.Primitive as PV main :: IO () main = do let fewNumbers = PV.replicate 10000000 1.00000001 manyNumbers = PV.replicate 100000000 1.00000001 defaultMain [ bgroup "serial" [ bench "few" $ whnf serialProduct fewNumbers , bench "many" $ whnf serialProduct manyNumbers ] , bgroup "parallel" [ bench "few" $ whnf parallelProduct fewNumbers , bench "many" $ whnf parallelProduct manyNumbers ] ] serialProduct :: PV.Vector Double -> Double serialProduct v = let !len = PV.length v go :: Double -> Int -> Double go !d !ix = if ix < len then go (d * PV.unsafeIndex v ix) (ix + 1) else d in go 1.0 0 -- | This only works when the vector length is a multiple of 4. parallelProduct :: PV.Vector Double -> Double parallelProduct v = runEval $ do let chunk = div (PV.length v) 4 p2 <- rpar (serialProduct (PV.slice (chunk * 1) chunk v)) p3 <- rpar (serialProduct (PV.slice (chunk * 2) chunk v)) p4 <- rpar (serialProduct (PV.slice (chunk * 3) chunk v)) p1 <- rseq (serialProduct (PV.slice (chunk * 0) chunk v)) rseq (p1 * p2 * p3 * p4) }}} We can build and run this with: {{{ > ghc -threaded parallel_compute.hs > ./parallel_compute +RTS -N6 }}} On my eight-core laptop, here are the results we get: {{{ benchmarking serial/few time 11.46 ms (11.29 ms .. 11.61 ms) 0.999 R² (0.998 R² .. 1.000 R²) mean 11.52 ms (11.44 ms .. 11.62 ms) std dev 222.8 μs (140.9 μs .. 299.6 μs) benchmarking serial/many time 118.1 ms (116.1 ms .. 120.0 ms) 1.000 R² (1.000 R² .. 1.000 R²) mean 117.2 ms (116.6 ms .. 117.9 ms) std dev 920.3 μs (550.5 μs .. 1.360 ms) variance introduced by outliers: 11% (moderately inflated) benchmarking parallel/few time 10.04 ms (9.968 ms .. 10.14 ms) 0.999 R² (0.999 R² .. 1.000 R²) mean 9.970 ms (9.891 ms .. 10.03 ms) std dev 172.9 μs (114.5 μs .. 282.9 μs) benchmarking parallel/many time 45.32 ms (43.55 ms .. 47.17 ms) 0.996 R² (0.993 R² .. 0.999 R²) mean 45.93 ms (44.71 ms .. 48.10 ms) std dev 3.041 ms (1.611 ms .. 4.654 ms) variance introduced by outliers: 20% (moderately inflated) }}} Interestingly, in the benchmark with the smaller 10,000,000 element vector, we see almost no performance improvement from the sparks. But, in the one with the larger 100,000,000 element vector, we see a considerable speedup. It runs 2.5-3.0x faster. The reason for this is that sparks are not started between scheduling intervals. By default, this happens every 20ms. We can see the fizzling like this: {{{ > ./parallel_compute 'parallel/few' +RTS -N6 -s benchmarking parallel/few ... SPARKS: 1536 (613 converted, 0 overflowed, 0 dud, 42 GC'd, 881 fizzled) ... > ./parallel_compute 'parallel/many' +RTS -N6 -s benchmarking parallel/many ... SPARKS: 411 (411 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) ... }}} For application developers, it's possible to work around this by tweaking the scheduling interval: {{{ > ghc -threaded -rtsopts parallel_compute.hs > ./parallel_compute 'parallel/few' +RTS -N6 -s -C0.001 benchmarking parallel/few time 4.158 ms (4.013 ms .. 4.302 ms) 0.993 R² (0.987 R² .. 0.998 R²) mean 4.094 ms (4.054 ms .. 4.164 ms) std dev 178.5 μs (131.5 μs .. 243.7 μs) variance introduced by outliers: 24% (moderately inflated) ... SPARKS: 3687 (3687 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) }}} Much better. But, there are two problems with this: 1. This may negatively impact the overall performance of an application. 2. It doesn't work at all for library developers. It isn't practical to tell end users of your to use certain runtime flags. I don't know enough about the RTS to suggest a way to improve this. However, intuitively, I would expect that if I spark something and there's an idle capability, the idle capability could immediately be given the spark instead of having it placed in the local queue. This may not be possible or may not be compatible with the minimal use of locks in the implementation of sparks though. Here is a comment I made in the StackOverflow thread: > I suppose that in the normal case, if you're going to be sparking things, you should ensure that the work done by all the sparks plus the main thread takes well over 20ms. Otherwise, nearly everything will fizzle unless scheduling happens to be coming soon. I've always wondered about the threshold for how fine-grained sparks should be, and my understanding is now that this is roughly it. In short, I'd like for it to be possible to realize some of the benefits of parallelism for computations that take under 20ms without resorting to `forkIO` and `MVar`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14330> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10827: GHCi should support interpeting multiple packages/units with separate DynFlags
by GHC 07 Sep '18

07 Sep '18

#10827: GHCi should support interpeting multiple packages/units with separate DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHC API | Version: 7.11 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Stack and other tools are attempting to make the user-experience of developing multiple packages simultaneously better. Thus, if you have source packages p, q and r (which all depend on them), `stack build` builds all of them. They are quite interested in support `stack ghci` but there are problems: https://github.com/commercialhaskell/stack/issues/665 The essence of the problem is twofold: 1. If you ask GHCi to interpret modules from multiple packages (e.g. by having multiple source directories), GHCi currently only knows how to put all of them into the same home package. This will fail if two packages have a module with the same name; also, modules in the other packages will always see modules (even if they're supposed to be hidden). 2. A GHCi session only has one global set of dynamic flags, but each package may be compiled with its own set of DynFlags (e.g. package global LANGUAGE pragmas). This means the "default DynFlags" needs to be varied between packages. It's not too obvious to me how to fix (1) (at least, you'd have to make the HPT support sets of HomeModInfos from multiple packages), but (2) seems tractable: since we already track DynFlags on a per-module basis, we just have to arrange for a "package" level DynFlag to be applied to the correct ModSummarys. Similar functionality would be useful for Backpack. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10827> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12356: StaticPointers support in GHCi
by GHC 07 Sep '18

07 Sep '18

#12356: StaticPointers support in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12000 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently GHCi does not support `-XStaticPointers`, which is quite annoying for those of us who actually use `-XStaticPointers` in day-to-day development. It would be great if GHCi could grow support for this extension. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12356> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #14743: `UnsafeReenter` test hangs
by GHC 07 Sep '18

07 Sep '18

#14743: `UnsafeReenter` test hangs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After a `./validate --slow` run `UnsafeReenter` process hangs forever, using CPU as well. Not sure if this happens in fast or normal validate yet, or which way do I need to reproduce. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14743> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9622: GHCi command to solve a constraint
by GHC 07 Sep '18

07 Sep '18

#9622: GHCi command to solve a constraint -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It would be nice to have a `:solve` command for ghci that took a class constraint and returned either its derivation or an error message. A possible interface could look like so: {{{ ghci> :solve Eq (Maybe Type1, Bool) 1) instance Eq Type1 -- Defined in ‘MyModule’ 2) instance Eq a => Eq (Maybe a) -- Defined in ‘GHC.Classes’ 3) instance Eq (Maybe Type1) -- Put a ~ Int in 2) and use 1) 4) instance Eq Bool -- Defined in ‘GHC.Classes’ 5) instance (Eq a, Eq b) => Eq (a,b) -- Defined in ‘GHC.Classes’ 6) instance Eq (Maybe Type1, Bool) -- Put a ~ Maybe Type1, b ~ Bool in 5) and use 3), 4) ghci> :solve Eq (Int -> Int) No instance for Eq (Int -> Int) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9622> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15427: Calling hs_try_putmvar from an unsafe foreign call can cause the RTS to hang
by GHC 06 Sep '18

06 Sep '18

#15427: Calling hs_try_putmvar from an unsafe foreign call can cause the RTS to hang -------------------------------------+------------------------------------- Reporter: syntheorem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.4.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- An unsafe foreign call which calls `hs_try_putmvar` can cause the RTS to hang, preventing any Haskell threads from making progress. However, compiling with `-debug` causes it instead to fail an assertion in the scheduler: {{{ internal error: ASSERTION FAILED: file rts/Schedule.c, line 510 (GHC version 8.4.3 for x86_64_apple_darwin) }}} Here is a minimal test case which reproduces the assertion. It needs to be built with `-debug -threaded` and run with `+RTS -N2` or higher. {{{#!hs import Control.Concurrent (forkIO, threadDelay) import Control.Concurrent.MVar (MVar, newEmptyMVar, takeMVar) import Control.Monad (forever) import Foreign.C.Types (CInt(..)) import Foreign.StablePtr (StablePtr) import GHC.Conc (PrimMVar, newStablePtrPrimMVar) foreign import ccall unsafe hs_try_putmvar :: CInt -> StablePtr PrimMVar -> IO () main = do mvar <- newEmptyMVar forkIO $ forever $ do takeMVar mvar forkIO $ forever $ do sp <- newStablePtrPrimMVar mvar hs_try_putmvar (-1) sp threadDelay 1 -- Let it spin a few times to trigger the bug threadDelay 500 }}} I actually checked out GHC and added this as a test case and did some debugging. The specific assertion that fails is `ASSERT(task->cap == cap)`. This seems to happen because of this code in `hs_try_putmvar`: {{{#!c Task *task = getTask(); // ... ACQUIRE_LOCK(&cap->lock); // If the capability is free, we can perform the tryPutMVar immediately if (cap->running_task == NULL) { cap->running_task = task; task->cap = cap; RELEASE_LOCK(&cap->lock); // ... releaseCapability(cap); } else { // ... } }}} Basically it assumes that the current thread's task isn't currently running a capability, so it takes a new one and then releases it without restoring the previous value of `task->cap`. Modifying the code to restore the value of `task->cap` after releasing the capability fixes the assertion. But I don't know enough about the RTS to be sure I'm not missing something here. In particular, is there a problem with the task basically holding two capabilities for a short time? My other thought is that maybe it should check if its task is currently running a capability, and in that case do something else. But I'm not sure what. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13499: "Panic: no skolem info" with StaticPointers and typed hole
by GHC 06 Sep '18

06 Sep '18

#13499: "Panic: no skolem info" with StaticPointers and typed hole -------------------------------------+------------------------------------- Reporter: Otini | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux StaticPointers, hole, skolem, | panic | Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling this minimal example: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE StaticPointers #-} import Data.Typeable (Typeable) import GHC.StaticPtr (StaticPtr) f :: Typeable a => StaticPtr (a -> a) f = static (\a -> _) main :: IO () main = return () }}} I get this output: {{{ Bug.hs:8:19: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): No skolem info: a_aJo[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Unlike similar reported bugs, this happens on both 8.0.1 and 8.0.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13499> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8