July 2018 - ghc-tickets

[GHC] #12736: Calling a complex Haskell function (obtained via FFI wrapper function) from MSVC 64-bit C code (passed in as FunPtr) can leave SSE2 registers in the XMM6-XMM15 range modified
by GHC 24 Jul '18

24 Jul '18

#12736: Calling a complex Haskell function (obtained via FFI wrapper function) from MSVC 64-bit C code (passed in as FunPtr) can leave SSE2 registers in the XMM6-XMM15 range modified -------------------------------------+------------------------------------- Reporter: bavism | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (FFI) | Keywords: | Operating System: Windows ffi,registers,sse2,clobber,xmm | Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: https://github.com/bavis-m/raycast | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- According to the [https://msdn.microsoft.com/en-us/library/9z1stfyw.aspx MSDN], in the Microsoft x64 architecture function calls must preserve the SSE2 registers in the range XMM6-XMM15. The Haskell FFI can produce a function pointer via dynamic wrapper that, when called from MSVC x64 C code, does not preserve these registers, causing further floating-point operations in the C code to fail. I can reproduce this error in [https://github.com/bavis-m/raycast this project], which is a DOOM-style raycasting engine written in Haskell, that imports a C DLL with glue for rendering and window management. The Haskell executable generates a FunPtr to a frame update function using the dynamic import mechanism, and passes this to a long-lived C function that runs the update loop. Any time this update function is called from the C loop, subsequent floating point operations produce incorrect results (in this case, the next operations compute a view matrix for the OpenGL window). The output on every frame showing the view matrix should be: {{{ viewM: 0.003125 0.000000 0.000000 -1.000000 0.000000 0.004167 0.000000 -1.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 }}} Running the raycaster with the Release version of the DLL causes the value of this matrix to be corrupted. There is a patch provided (stub.patch in the root folder) that turns the Haskell update function into an empty stub. This causes the program to work. When stepping through the assembly code with this patch applied, I can see in the function prologue where the XMM registers are saved. Without the patch, these registers are not saved. Running the Debug version does not show this error; the register allocation must be different. I have been attempting to create a much simpler test case to reveal this code-generation issue, however it has been difficult. Even seemingly trivial changes can cause the bug to not show up, it is clearly dependent on the register allocation used internally to produce the assembly code. Instructions for building the project are in the readme. (You will need the Haskell Stack Tool, and Visual Studio 15). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12736> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15435: Make nofib-style anaysis for perf/compiler
by GHC 24 Jul '18

24 Jul '18

#15435: Make nofib-style anaysis for perf/compiler -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- The compiler runtime tests in `perf/compiler` only complain if the perf gets worse by more than 5% or 10% or whatever (varies by test). I would '''love''' it if I could get a `nofib-analyse` style comparison of these benchmarks, comparing the compiler perf before and after some patch I've made. At the moment I simply can't do this comparison in a time-effective way. If we could generate a log-file in the right format, `nofib-analyse` might already do the job. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15435> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8740: Code conditionally compiles
by GHC 24 Jul '18

24 Jul '18

#8740: Code conditionally compiles ----------------------------+---------------------------------------------- Reporter: | Owner: thomaseding | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: MacOS X Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- {{{ {-# LANGUAGE GADTs #-} {-# LANGUAGE StandaloneDeriving #-} data Abstract data Reified data Player data Elect p a where ElectRefAsTypeOf :: Int -> Elect Abstract a -> Elect Abstract a ElectHandle :: a -> Elect Reified a Controller :: Elect Abstract Player Owner :: Elect Abstract Player You :: Elect Abstract Player deriving instance (Eq a) => Eq (Elect p a) deriving instance (Ord a) => Ord (Elect p a) }}} As is, the above code fails to compile. But if I move `ElectRefAsTypeOf` to be the last constructor for the GADT, the code does compile. If I remove one of the `Elect Abstract Player` constructors, the code still won't compile even if the `ElectRefAsTypeOf` is moved. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8740> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8128: Standalone deriving fails for GADTs due to inaccessible code
by GHC 24 Jul '18

24 Jul '18

#8128: Standalone deriving fails for GADTs due to inaccessible code -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Consider the following: {{{ {-# LANGUAGE StandaloneDeriving, GADTs, FlexibleInstances #-} module StandaloneDerivingGADT where data T a where MkT1 :: T Int MkT2 :: (Bool -> Bool) -> T Bool deriving instance Show (T Int) }}} This gives the error: {{{ StandaloneDerivingGADT.hs:9:1: Couldn't match type ‛Int’ with ‛Bool’ Inaccessible code in a pattern with constructor MkT2 :: (Bool -> Bool) -> T Bool, in an equation for ‛showsPrec’ In the pattern: MkT2 b1 In an equation for ‛showsPrec’: showsPrec a (MkT2 b1) = showParen ((a >= 11)) ((.) (showString "MkT2 ") (showsPrec 11 b1)) When typechecking the code for ‛showsPrec’ in a standalone derived instance for ‛Show (T Int)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‛Show (T Int)’ }}} The derived instance declaration matches on all the constructors, even if they cannot possibly match. It should omit obviously inaccessible constructors so that this example is accepted. For reference, the derived code is: {{{ instance GHC.Show.Show (StandaloneDerivingGADT.T GHC.Types.Int) where GHC.Show.showsPrec _ StandaloneDerivingGADT.MkT1 = GHC.Show.showString "MkT1" GHC.Show.showsPrec a_aij (StandaloneDerivingGADT.MkT2 b1_aik) = GHC.Show.showParen ((a_aij GHC.Classes.>= 11)) ((GHC.Base..) (GHC.Show.showString "MkT2 ") (GHC.Show.showsPrec 11 b1_aik)) GHC.Show.showList = GHC.Show.showList__ (GHC.Show.showsPrec 0) }}} The same problem applies to other derivable classes (e.g. `Eq`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8128> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #14333: GHC doesn't use the fact that Coercible is symmetric
by GHC 23 Jul '18

23 Jul '18

#14333: GHC doesn't use the fact that Coercible is symmetric -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- {{{#!hs {-# Language ScopedTypeVariables, GADTs, DeriveGeneric #-} import GHC.Generics import Data.Type.Coercion data AB = A | B deriving (Generic) data XY = X | Y deriving (Generic) data This ab xy where At :: This AB XY foo :: This ab xy -> Coercion (Rep ab a) (Rep xy a) foo At = Coercion bar :: forall ab xy a. This ab xy -> Coercion (Rep ab a) (Rep xy a) bar at | Coercion <- foo at :: Coercion (Rep ab a) (Rep xy a) = Coercion }}} This compiles on 8.2.1 and 8.3.20170920 but flipping the arguments to `Coercion` fails {{{#!hs -- ... -- • Could not deduce: Coercible (Rep xy a) (Rep ab a) -- arising from a use of ‘Coercion’ -- from the context: Coercible (Rep ab a) (Rep xy a) -- bound by a pattern with constructor: bar :: forall ab xy a. This ab xy -> Coercion (Rep xy a) (Rep ab a) bar at | Coercion <- foo at :: Coercion (Rep ab a) (Rep xy a) = Coercion }}} Conceptually there should be an (`Undecidable`) superclass constraint for `Coercible` {{{#!hs class Coercible b a => Coercible a b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14333> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x)
by GHC 23 Jul '18

23 Jul '18

#15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE DeriveTraversable #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE UndecidableInstances #-} module Foo where import Data.Kind type family F a :: Type -> Type newtype WrappedF a b = WrapF (F a b) deriving instance Functor (F a) => Functor (WrappedF a) deriving instance Foldable (F a) => Foldable (WrappedF a) deriving instance Traversable (F a) => Traversable (WrappedF a) data SomeF b = forall a. MkSomeF (WrappedF a b) deriving instance (forall a. Functor (WrappedF a)) => Functor SomeF deriving instance (forall a. Foldable (WrappedF a)) => Foldable SomeF deriving instance ( forall a. Functor (WrappedF a) , forall a. Foldable (WrappedF a) , forall a. Traversable (WrappedF a) ) => Traversable SomeF }}} This typechecks. However, the last `Traversable SomeF` is a bit unfortunate in that is uses three separate `forall a.`s. I attempted to factor this out, like so: {{{#!hs deriving instance (forall a. ( Functor (WrappedF a) , Foldable (WrappedF a) , Traversable (WrappedF a) )) => Traversable SomeF }}} But then the file no longer typechecked! {{{ $ /opt/ghc/8.6.1/bin/ghc Foo.hs [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Foo.hs:21:1: error: • Could not deduce (Functor (F a)) arising from the superclasses of an instance declaration from the context: forall a. (Functor (WrappedF a), Foldable (WrappedF a), Traversable (WrappedF a)) bound by the instance declaration at Foo.hs:(21,1)-(24,52) • In the instance declaration for ‘Traversable SomeF’ | 21 | deriving instance (forall a. ( Functor (WrappedF a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Foo.hs:21:1: error: • Could not deduce (Foldable (F a)) arising from the superclasses of an instance declaration from the context: forall a. (Functor (WrappedF a), Foldable (WrappedF a), Traversable (WrappedF a)) bound by the instance declaration at Foo.hs:(21,1)-(24,52) • In the instance declaration for ‘Traversable SomeF’ | 21 | deriving instance (forall a. ( Functor (WrappedF a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Foo.hs:21:1: error: • Could not deduce (Traversable (F a1)) arising from a use of ‘traverse’ from the context: forall a. (Functor (WrappedF a), Foldable (WrappedF a), Traversable (WrappedF a)) bound by the instance declaration at Foo.hs:(21,1)-(24,52) or from: Applicative f bound by the type signature for: traverse :: forall (f :: * -> *) a b. Applicative f => (a -> f b) -> SomeF a -> f (SomeF b) at Foo.hs:(21,1)-(24,52) • In the second argument of ‘fmap’, namely ‘(traverse f a1)’ In the expression: fmap (\ b1 -> MkSomeF b1) (traverse f a1) In an equation for ‘traverse’: traverse f (MkSomeF a1) = fmap (\ b1 -> MkSomeF b1) (traverse f a1) When typechecking the code for ‘traverse’ in a derived instance for ‘Traversable SomeF’: To see the code I am typechecking, use -ddump-deriv | 21 | deriving instance (forall a. ( Functor (WrappedF a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} Richard suspects that this is a bug in the way quantified constraints expands superclasses, so I decided to post it here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15334> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15419: GHC 8.6.1 regression (buildKindCoercion)
by GHC 23 Jul '18

23 Jul '18

#15419: GHC 8.6.1 regression (buildKindCoercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program typechecks on GHC 8.4.1, but panics on GHC 8.6.1 and HEAD: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Kind data family Sing :: forall k. k -> Type data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 data instance Sing :: forall a b. (a, b) -> Type where STuple2 :: Sing x -> Sing y -> Sing '(x, y) newtype instance Sing (f :: k1 ~> k2) = SLambda { applySing :: forall t. Sing t -> Sing (f `Apply` t) } ----- newtype Par1 p = Par1 p newtype K1 c p = K1 c data (f :*: g) p = f p :*: g p data instance Sing :: forall p. Par1 p -> Type where SPar1 :: Sing x -> Sing ('Par1 x) data instance Sing :: forall k c (p :: k). K1 c p -> Type where SK1 :: Sing x -> Sing ('K1 x) data instance Sing :: forall k (f :: k -> Type) (g :: k -> Type) (p :: k). (f :*: g) p -> Type where (:%*:) :: Sing x -> Sing y -> Sing (x ':*: y) class Generic1 (f :: k -> Type) where type Rep1 f :: k -> Type from1 :: f a -> Rep1 f a to1 :: Rep1 f a -> f a class PGeneric1 (f :: k -> Type) where type From1 (z :: f a) :: Rep1 f a type To1 (z :: Rep1 f a) :: f a class SGeneric1 (f :: k -> Type) where sFrom1 :: forall (a :: k) (z :: f a). Sing z -> Sing (From1 z) sTo1 :: forall (a :: k) (r :: Rep1 f a). Sing r -> Sing (To1 r :: f a) instance Generic1 ((,) a) where type Rep1 ((,) a) = K1 a :*: Par1 from1 (x, y) = K1 x :*: Par1 y to1 (K1 x :*: Par1 y) = (x, y) instance PGeneric1 ((,) a) where type From1 '(x, y) = 'K1 x ':*: 'Par1 y type To1 ('K1 x ':*: 'Par1 y) = '(x, y) instance SGeneric1 ((,) a) where sFrom1 (STuple2 x y) = SK1 x :%*: SPar1 y sTo1 (SK1 x :%*: SPar1 y) = STuple2 x y ----- type family GenericFmap (g :: a ~> b) (x :: f a) :: f b where GenericFmap g x = To1 (Fmap g (From1 x)) class PFunctor (f :: Type -> Type) where type Fmap (g :: a ~> b) (x :: f a) :: f b type Fmap g x = GenericFmap g x class SFunctor (f :: Type -> Type) where sFmap :: forall a b (g :: a ~> b) (x :: f a). Sing g -> Sing x -> Sing (Fmap g x) default sFmap :: forall a b (g :: a ~> b) (x :: f a). ( SGeneric1 f, SFunctor (Rep1 f) , Fmap g x ~ GenericFmap g x ) => Sing g -> Sing x -> Sing (Fmap g x) sFmap sg sx = sTo1 (sFmap sg (sFrom1 sx)) ----- instance PFunctor Par1 where type Fmap f ('Par1 x) = 'Par1 (f `Apply` x) instance PFunctor (K1 c) where type Fmap _ ('K1 x) = 'K1 x instance PFunctor (f :*: g) where type Fmap h (x ':*: y) = Fmap h x ':*: Fmap h y instance SFunctor Par1 where sFmap sf (SPar1 sx) = SPar1 (sf `applySing` sx) instance SFunctor (K1 c) where sFmap _ (SK1 sx) = SK1 sx instance (SFunctor f, SFunctor g) => SFunctor (f :*: g) where sFmap sh (sx :%*: sy) = sFmap sh sx :%*: sFmap sh sy ----- instance PFunctor ((,) a) -- The line below causes the panic instance SFunctor ((,) a) }}} {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.0.20180714 for x86_64-unknown-linux): buildKindCoercion K1 a_a1Nj :*: Par1 Rep1 ((,) a_a1Nj) * a_a1Nj Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/types/Coercion.hs:2069:9 in ghc:Coercion }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15419> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15432: Referring to current module (or aliasing current module)
by GHC 23 Jul '18

23 Jul '18

#15432: Referring to current module (or aliasing current module) -------------------------------------+------------------------------------- Reporter: moll | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Hey, Suppose I got a record type `Game` in a module `Lib.Game` that has a field `player`. I'd occasionally like to use the variable `player` in a closure, but still refer to the `player` field accessor once to assign the variable. Is it me or right now there's no way to refer to the current module by anything other than its full name? That is, to disambiguate the variable and function, I have to type `let player = Lib.Game.player`. In other words, I'd like the invocation of `Lib.Game.player` below to be shortened somehow, either by assigning an alias to the current module via `import qualified` (can't now as it results in a self-cycle) or by some other means of referring to the closing module. {{{#!hs module Lib.Game where data Game = Game {player :: Player} play game = foo player where player = Lib.Game.player game }}} This is vaguely similar to https://ghc.haskell.org/trac/ghc/ticket/10336, but the `SOURCE` pragma seems to be about actually cyclical imports. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15432> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14414: Profiled program runs 2.5x faster than non-profiled
by GHC 23 Jul '18

23 Jul '18

#14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- I was looking at benchmarks game (attached as fasta.ghc-2.hs). I have found that with the flags give there, this program on GHC 8.2.1 runs in about a second with `-prof -fprof-auto` and 2.5 seconds without! To run without profiling: {{{ ghc --make -Wall -fforce-recomp -fllvm -O2 -XBangPatterns -threaded -rtsopts -XOverloadedStrings fasta.ghc-2.hs -o fasta.ghc-2.ghc_run && ./fasta.ghc-2.ghc_run +RTS -N4 -s -RTS 250000 > /dev/null }}} Same program with profiling {{{ ghc --make -fforce-recomp -fllvm -prof -fprof-auto -O2 -XBangPatterns -threaded -rtsopts -XOverloadedStrings fasta.ghc-2.hs -o fasta.ghc-2.ghc_run && ./fasta.ghc-2.ghc_run +RTS -N4 -p -s -RTS 250000 > /dev/null }}} I also attach Core outputs for both profiled and unprofiled version. To me this seems very strange: profiled version is somehow faster. Perhaps what's worse is that this means that there's some optimisation GHC is performing when profiling is not on that makes the program a lot slower than it could be! This program is not minimised. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14414> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12714: T9405 fails on Windows
by GHC 22 Jul '18

22 Jul '18

#12714: T9405 fails on Windows --------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- The `T9405` testcase currently fails on Windows, {{{ }}} Contrary to what was suggested in ticket:12004#comment:3 it looks like the problem is that an empty `.ticky` file is produced. Even increasing the `sleep` time to 10 seconds (after bumping the sleep in `T9405.hs` accordingly) doesn't change this, so I suspect there is a runtime system bug here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7