August 2016 - ghc-tickets

Re: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2.
by GHC 26 Aug '16

26 Aug '16

#5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: | daniel.is.fischer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Looks like it! I'd look carefully at comment:19 and its links. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5615#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2.
by GHC 26 Aug '16

26 Aug '16

#5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: | daniel.is.fischer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) Comment: Am I right that for `div` and `mod` this is just waiting to be implemented (in PrelRules)? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5615#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12541: RFC: Implicit parentheses in GHCi
by GHC 25 Aug '16

25 Aug '16

#12541: RFC: Implicit parentheses in GHCi -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.0.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've been making a few tickets lately that aren't technical but small things that would streamline my interactive experience. Please close if this is not the place for it. ''Caveat lector'': long and boring read ahead. = Code = {{{#!hs data Op = Add | Mul deriving Show data Exp = Op Op | Lit Int | Exp :$ Exp deriving Show infixl :$ }}} = Motivation = I often want to see the “progression” of applying an operator to arguments one by one. There are several ways of doing this: {{{#!hs >>> :t (:$) >>> :t (Op Add :$) >>> :t Op Add :$ Lit 10 }}} {{{#!hs >>> :t (:$) >>> :t (Op Add :$) >>> :t (Op Add :$) (Lit 10) }}} {{{#!hs >>> :t (:$) >>> :t (:$) (Op Add) >>> :t (:$) (Op Add) (Lit 10) }}} {{{#!hs >>> :t (:$) >>> :t (:$) (Op Add) >>> :t Op Add :$ Lit 10 }}} Look at all of those parentheses! Every step adds or removes (or requires navigation around) parentheses. = `tl;dr`: this is annoying to type = I'm writing this out in full not just because I get a sick joy out of it but to hammer the point home. === First example === We wrap `:$` in parentheses, navigate around them to make a section and then remove them: {{{#!hs >>> >>> :t (:$)␣ -- C-m >>> -- C-p >>> :t (:$)␣ -- C-a >>> ␣:t (:$) -- C-f, C-f, C-f, C-f >>> :t (␣:$) >>> :t (Op Add ␣:$) -- C-m >>> -- C-p >>> :t (Op Add :$)␣ -- C-h >>> :t (Op Add :$␣ >>> :t (Op Add :$ Lit 10 -- C-a >>> ␣:t (Op Add :$ Lit 10 -- C-f, C-f, C-f >>> :t ␣(Op Add :$ Lit 10 -- C-d >>> :t ␣Op Add :$ Lit 10 }}} === Second example === We wrap `:$` in parentheses, navigate around them to make a section and then wrap the argument in parentheses: {{{#!hs >>> >>> :t (:$)␣ -- C-m >>> -- C-p >>> :t (:$)␣ -- C-a >>> ␣:t (:$) -- C-f, C-f, C-f, C-f >>> :t (␣:$) >>> :t (Op Add ␣:$) -- C-m >>> -- C-p >>> :t (Op Add :$)␣ >>> :t (Op Add :$) (Lit 10)␣ }}} === Third example === Wrap everything in parentheses, on a good day I will remember that the arguments need parentheses: {{{#!hs >>> >>> :t (:$)␣ -- C-m >>> -- C-p >>> :t (:$)␣ >>> :t (:$) (Op Add)␣ -- C-m >>> -- C-p >>> :t (:$) (Op Add)␣ >>> :t (:$) (Op Add) (Lit 10)␣ }}} ((On every other day I will forget that `Op Add` is an application and write..)) {{{#!hs >>> :t (:$)␣ >>> :t (:$) Add␣ -- M-b >>> :t (:$) ␣Add >>> :t (:$) (Op ␣Add -- C-e >>> :t (:$) (Op Add␣ >>> :t (:$) (Op Add)␣ }}} === Fourth example === Wrap operator and argument, remove both pairs of parentheses: {{{#!hs >>> >>> :t (:$)␣ -- C-m >>> -- C-p >>> :t (:$)␣ >>> :t (:$) (Op Add)␣ -- C-m >>> -- C-p >>> :t (:$) (Op Add)␣ -- C-a >>> ␣:t (:$) (Op Add) -- C-f, C-f, C-f >>> :t ␣(:$) (Op Add) -- C-d, C-d, ... >>> :t ␣Op Add) -- C-e >>> :t Op Add)␣ -- C-h >>> :t Op Add␣ >>> :t Op Add :$ Lit 10␣ }}} = Proposal = Long story short this involves a lot of manipulation of terms (deleting/rewriting, cutting/pasting), jumping around and adding or removing parentheses. My proposal is to make GHCi a bit smarter in how it accepts operators and sections, to a first approximation it would be as if there were implicit `'(' ++ cmd ++ ')'` around the command. Let's see how I picture this would work: {{{#!hs >>> :t :$ >>> :t Op Add :$ >>> :t Op Add :$ Lit 10 }}} This may feel disconcerting since this is not valid syntax for operators or sections, but I think it would be fine. For example both `:info :$` and `:info (:$)` work. This would take me a lot less time to write! No parentheses and minimal jumping around. This would make it very simple to get the right section of an operator: {{{#!hs >>> :t >>= >>> :t >>= id }}} and could be extended to work with infix functions as well, I would probably use `flip` a whole lot less: {{{#!hs >>> :t `take` -- ^ probably shouldn't work, but allows for less skipping >>> :t `take` "wabalabadubdub" >>> :t 10 `take` "wabalabadubdub" }}} The reason why I said “to a first approximation” is that `:$) (Op Add` should obviously not be valid. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12541> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11443: SPECIALIZE pragma does not work + performance drop in GHC 8.0-rc1
by GHC 25 Aug '16

25 Aug '16

#11443: SPECIALIZE pragma does not work + performance drop in GHC 8.0-rc1 -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- Hello! I've just hit a strange issue. I might missinterpret how the `SPECIALIZE` pragma works, but if I understand correctly, then there is a bug in GHC. Lets consider this simple code: module `A`: {{{ {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} module A where import Prelude import GHC.TypeLits -- TF utils type family (a :: Nat) :== (b :: Nat) where a :== a = 'True a :== b = 'False type family If cond (a :: Nat) (b :: Nat) where If 'True a b = a If 'False a b = b -- Heavy TF computations type family HeavyTF (n :: Nat) (i :: Nat) :: Nat where HeavyTF n 0 = 0 HeavyTF n i = If (HeavyTF' n :== 0) (HeavyTF n (i - 1)) 1 type family HeavyTF' (n :: Nat) :: Nat where HeavyTF' 0 = 0 HeavyTF' n = HeavyTF' (n - 1) -- Params for tests (bigger numbers = longer compile times) type family NatOf a :: Nat type instance NatOf Int = 12000 type instance NatOf String = 12000 -- Type class to check GHC behavior class PerfC1 a where perfc1 :: a -> String instance CheckOk (HeavyTF 10 (NatOf a)) => PerfC1 a where perfc1 _ = "oh" ; {-# INLINABLE perfc1 #-} class CheckOk (n :: Nat) instance CheckOk 0 -- where main_cache :: IO () main_cache = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) perfc1_Int :: Int -> String perfc1_Int = perfc1 perfc1_String :: String -> String perfc1_String = perfc1 {-# SPECIALIZE perfc1 :: Int -> String #-} {-# SPECIALIZE perfc1 :: String -> String #-} ----- perfc1' :: PerfC1 a => a -> String perfc1' = perfc1 {-# INLINABLE perfc1' #-} {-# SPECIALIZE perfc1' :: Int -> String #-} {-# SPECIALIZE perfc1' :: String -> String #-} }}} module `Test1`: {{{ import A main = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) }}} module `Test2`: {{{ import A main = do print $ perfc1' (1 :: Int) print $ perfc1' ("a" :: String) }}} module `Test3`: {{{ import A main = do print $ perfc1_Int (1 :: Int) print $ perfc1_String ("a" :: String) }}} Compile with: `ghc 7.10.3` : `ghc -O2 -fenable-rewrite-rules Test<n>.hs` `ghc 8.0-rc1` : `ghc -O2 -fenable-rewrite-rules -freduction-depth=0 Test<n>.hs` If module `A` was already compiled the compilation times for `ghc 7.10.3` were as follow: - `Test1`: ~ 16s - `Test2`: ~ 16s - `Test3`: almost instant And for `ghc 8.0-rc1` were as follow: - `Test1`: ~ 28s - `Test2`: ~ 28s - `Test3`: almost instant Here are 2 bugs to note: 1) the compilation times are much longer with new GHC 2) the specialize pragmas do not work -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11443> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #12077: T8761 (Make pattern synonyms work with Template Haskell) is failing on Travis
by GHC 25 Aug '16

25 Aug '16

#12077: T8761 (Make pattern synonyms work with Template Haskell) is failing on Travis -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #8761 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Note that Travis uses `DYNAMIC_GHC_PROGRAMS=NO`. First failure: https://travis-ci.org/ghc/ghc/builds/129738012 {{{ Actual stderr output differs from expected: --- ./th/T8761.stderr.normalised 2016-05-12 15:08:16.512921981 +0000 +++ ./th/T8761.comp.stderr.normalised 2016-05-12 15:08:16.512921981 +0000 @@ -1,7 +1,3 @@ -pattern Q1 x1_0 x2_1 x3_2 <- ((x1_0, x2_1), [x3_2], _, _) -pattern x1_0 Q2 x2_1 = ((x1_0, x2_1)) -pattern Q3 {qx3, qy3, qz3} <- ((qx3, qy3), [qz3]) where - Q3 qx3 qy3 qz3 = ((qx3, qy3), [qz3]) T8761.hs:(15,1)-(38,13): Splicing declarations do { [qx1, qy1, qz1] <- mapM (/ i -> newName $ "x" ++ show i) [1, 2, 3]; @@ -123,30 +119,6 @@ pattern Pup x <- MkUnivProv x pattern Puep :: forall a. forall b. Show b => a -> b -> (ExProv, a) pattern Puep x y <- (MkExProv y, x) -pattern T8761.P :: GHC.Types.Bool -pattern T8761.Pe :: () => forall (a0_0 :: *) . a0_0 -> T8761.Ex -pattern T8761.Pu :: forall (a0_0 :: *) . a0_0 -> a0_0 -pattern T8761.Pue :: forall (a0_0 :: *) . () => forall (b0_1 :: *) . - a0_0 -> b0_1 -> (a0_0, T8761.Ex) -pattern T8761.Pur :: forall (a0_0 :: *) . (GHC.Num.Num a0_0, - GHC.Classes.Eq a0_0) => - a0_0 -> [a0_0] -pattern T8761.Purp :: forall (a0_0 :: *) (b0_1 :: *) . (GHC.Num.Num a0_0, - GHC.Classes.Eq a0_0) => - GHC.Show.Show b0_1 => a0_0 -> b0_1 -> ([a0_0], T8761.UnivProv b0_1) -pattern T8761.Pure :: forall (a0_0 :: *) . (GHC.Num.Num a0_0, - GHC.Classes.Eq a0_0) => - forall (b0_1 :: *) . a0_0 -> b0_1 -> ([a0_0], T8761.Ex) -pattern T8761.Purep :: forall (a0_0 :: *) . (GHC.Num.Num a0_0, - GHC.Classes.Eq a0_0) => - forall (b0_1 :: *) . GHC.Show.Show b0_1 => - a0_0 -> b0_1 -> ([a0_0], T8761.ExProv) -pattern T8761.Pep :: () => forall (a0_0 :: *) . GHC.Show.Show a0_0 => - a0_0 -> T8761.ExProv -pattern T8761.Pup :: forall (a0_0 :: *) . () => GHC.Show.Show a0_0 => - a0_0 -> T8761.UnivProv a0_0 -pattern T8761.Puep :: forall (a0_0 :: *) . () => forall (b0_1 :: *) . GHC.Show.Show b0_1 => - a0_0 -> b0_1 -> (T8761.ExProv, a0_0) T8761.hs:(107,1)-(111,25): Splicing declarations do { infos <- mapM reify *** unexpected failure for T8761(normal) }}} @bollmann added the test in c079de3c43704ea88f592e441389e520313e30ad. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12077> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12489: undefined in view pattern inside pattern synonym causes GHC to panic
by GHC 25 Aug '16

25 Aug '16

#12489: undefined in view pattern inside pattern synonym causes GHC to panic -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following: {{{#!hs {-# LANGUAGE PatternSynonyms, ViewPatterns #-} pattern P :: a -> b pattern P a <- (undefined -> a) }}} causes GHC HEAD and 8.0.1 to panic: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160813 for x86_64-unknown-linux): StgCmmEnv: variable not found }}} Removing the pattern signature or moving `undefined` behind another name work however: {{{#!hs {-# LANGUAGE PatternSynonyms, ViewPatterns #-} bottom :: a bottom = undefined pattern P :: a -> b pattern P a <- (bottom -> a) -- OK! -- No type signature pattern P' a <- (undefined -> a) -- OK! }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12489> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12406: New not-in-scope behaviour + deferred typed holes = disappearing error messages
by GHC 25 Aug '16

25 Aug '16

#12406: New not-in-scope behaviour + deferred typed holes = disappearing error messages -------------------------------------+------------------------------------- Reporter: ertes | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code snippet (using the [https://hackage.haskell.org/package /ref-tf ref-tf library]) is well-typed, and GHC is fine with it: {{{#!hs import Control.Monad -- comment this out to cause error import Control.Monad.Ref main :: IO () main = newRef (pure ()) >>= join . readRef }}} However, if one comments out the first line, then GHC treats `join` as a typed hole due to #10569, but fails to infer its type, causing errors: {{{ test.hs:10:8-23: error: … • Couldn't match type ‘Ref m0’ with ‘GHC.IORef.IORef’ ... test.hs:10:29-32: error: … Variable not in scope: join :: m0 (f0 ()) -> IO () }}} By default the not-in-scope error is reported, but if `-fdefer-typed- holes` is in effect, only the type error is reported leaving the user (at least me) puzzled. Not-in-scope errors should ''always'' be reported. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12406> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12484: Missing pattern synonym signatures gives incorrect fix
by GHC 25 Aug '16

25 Aug '16

#12484: Missing pattern synonym signatures gives incorrect fix -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #11053 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following pattern definition {{{#!hs pattern RP pname help type' <- ParamDesc pname help type' Required where RP pname help type' = ParamDesc pname help type' Required }}} Gives the warning {{{ /....../PluginTypes.hs:248:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: RP :: ParamName -> ParamHelp -> ParamType -> ParamDescription }}} The required signature is in fact {{{#!hs pattern RP :: ParamName -> ParamHelp -> ParamType -> ParamDescription }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12484> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12062: Parallel make with -j0 and hs-boot leads to floating point exception
by GHC 25 Aug '16

25 Aug '16

#12062: Parallel make with -j0 and hs-boot leads to floating point exception -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Runtime | Version: 8.0.1-rc2 System | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I run https://ghc.haskell.org/trac/ghc/ticket/1012#comment:5 with `ghc-8.0 --make ModuleB.hs -j0 -fforce-recomp` (the `-j0` is important) I get a `Floating point exception (core dumped)`. When I run under GDB, I get: {{{ (gdb) r Starting program: /srv/code/ghc-8.0.0.20160204/usr/lib/ghc-8.0.0.20160204/bin/ghc -B/home/ezyang/Dev/ghc-8.0.0.20160204/usr/lib/ghc-8.0.0.20160204 --make ModuleB.hs -j0 -fforce-recomp [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffecd7f700 (LWP 28877)] [New Thread 0x7fffe7fff700 (LWP 28878)] [New Thread 0x7fffe77fe700 (LWP 28879)] [1 of 4] Compiling ModuleA[boot] ( ModuleA.hs-boot, ModuleA.o-boot ) [2 of 4] Compiling ModuleC ( ModuleC.hs, ModuleC.o ) [3 of 4] Compiling ModuleA ( ModuleA.hs, ModuleA.o ) [4 of 4] Compiling ModuleB ( ModuleB.hs, ModuleB.o ) Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 0x7fffecd7f700 (LWP 28877)] schedule (initialCapability=<optimized out>, task=task@entry=0x7b6310) at rts/Schedule.c:373 373 rts/Schedule.c: No such file or directory. (gdb) bt #0 schedule (initialCapability=<optimized out>, task=task@entry=0x7b6310) at rts/Schedule.c:373 #1 0x00007fffed65018c in scheduleWorker (cap=<optimized out>, task=0x7b6310) at rts/Schedule.c:2378 #2 0x00007ffff738a6aa in start_thread (arg=0x7fffecd7f700) at pthread_create.c:333 #3 0x00007fffed14fe9d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 }}} I once got a different error running this: {{{ warning: Corrupted shared library list: 0x7e1ee0 != 0x7ffff7ffd9d8 }}} Looking at the code which is a `capabilities[cap->no % enabled_capabilities]`, I guess this is just something goofy, like GHC not rejecting `-j0` and then however we're setting the capabilities not checking this case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12062> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12419: Scheduling bug with forkOS + MVar
by GHC 25 Aug '16

25 Aug '16

#12419: Scheduling bug with forkOS + MVar -----------------------------------------+--------------------------------- Reporter: luisgabriel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Keywords: forkOS; scheduler | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -----------------------------------------+--------------------------------- I have noticed a weird scheduling behavior when performing some experiments with the '''fasta''' benchmark [1] from The Computer Language Benchmarks Game. When I switch `forkIO` by `forkOS` the scheduler stops to assign work for some capabilities, and they stay idle for the whole execution of the program. ThreadScope view using forkIO: https://s31.postimg.org/r3mclspe3/fork_IO_N8_ghc8.png ThreadScope view using forkOS: https://s31.postimg.org/p9n265fff/fork_OS_N8_ghc8.png I was able to reproduce this behavior in both '''GHC 7.10.2''' and '''GHC 8.0.2'''. I was also able to reproduce it on two different machines running Ubuntu Server 14.04.3 LTS (kernel 3.19.0-25): - 2x10-core Intel Xeon E5-2660 v2 processors (Ivy Bridge), 2.20 GHz, with 256GB of DDR 1600MHz - 4-core Intel i7-3770 (IvyBridge) with 8 GB of DDR 1600MHz Source code + .eventlog files: https://dl.dropboxusercontent.com/u/5798150 /fasta-bug.zip [1] http://benchmarksgame.alioth.debian.org/u64q/program.php?test=fasta&lang=gh… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12419> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17