- ghc-tickets - Haskell.org

[GHC] #14787: Remove StgLint type checks
by GHC 18 Feb '18

18 Feb '18

#14787: Remove StgLint type checks -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- Copying from the mailing list thread: ---- https://mail.haskell.org/pipermail/ghc-devs/2018-February/015371.html I've been looking into some StgLint-related tickets: - #13994: Found a StgLint problem and fixed, there's another problem waiting to be fixed. Both related with the fact that after unarisation we lose even more typing information and type checks needs to be relaxed. - #14116: StgLint failed to look through newtypes, and because coercions are removed at that point it failed to type check. Solution was to relax type checks. - #5345: Because `unsafeCoerce# is operationally no-op, and we don't have coercions in STG, StgLint can't type check at all. The commit message notes: > Fundamentally STG Lint is impossible, because unsafeCoerce# > can randomise all the types. > This patch does a bit of fiddle faddling in StgLint which > makes it a bit better, but it's a losing battle. - #14117: Related with StgLint not keeping up with recent changes (join points), because it's not enabled by default in tests/validate. - #14118: Related with the fact that pre- and post-unarise we have different invariants in STG. Solution was to add a "unarise" parameter and do different checks based on that. - #14120: Again type checking errors. Commit for #14116 also fixes this. The commits compares `typePrimRep`s of types instead of comparing actual types (even this is not enough, see #13994). All this of course took time to debug. In addition, the new `StgCSE` pass makes transformations that trigger case alternative checks (and probably some other checks) because scrutinee and result won't have same types after the transformation described in `Note [Case 2: CSEing case binders]`. There's also this comment in StgLint.hs WARNING: ~~~~~~~~ This module has suffered bit-rot; it is likely to yield lint errors for Stg code that is currently perfectly acceptable for code generation. Solution: don't use it! (KSW 2000-05). It seems like it hasn't been used since 2000. All this suggests that - Checks related to types are impossible in StgLint. (see e.g. commit messages in #5345, #1420, transformations done by unariser and StgCSE) - It's not enabled since 2000, which I think means that it's not needed. This makes me question whether it's worth maintaining. Maybe we should just remove it. If we still want to keep we should decide on what it's supposed to do. Only invariants I can think of are: - After unarise there should be no unboxed tuple and sum binders. unarise is a simple pass and does same thing to all binders, there are no tricky cases so I'm not sure if we need to check this. - Variables should be defined before use. I again don't know if this should be checked, could this be useful for StgCSE? So I think we should do one of these: 1. Remove StgLint. 2. Rewrite it to only check these two and nothing else, enable it in validate (and in other build flavours that enable CoreLint). What do you think? If you think we should keep StgLint, can you think of any other checks? If we could reach a consensus I'm hoping to update StgLint (or remove it). ---- Simon suggested creating a ticket and keeping StgLint. This is the tracking ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14787> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14763: GHC 8.4.1-alpha regression with FunctionalDependencies
by GHC 18 Feb '18

18 Feb '18

#14763: GHC 8.4.1-alpha regression with FunctionalDependencies -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 (Type checker) | Keywords: FunDeps | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This regression prevents `esqeueleto-2.5.3` from building with GHC 8.4.1. Here is a minimized example of the problem: {{{#!hs {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} module Bug where data Value a = Value a data SomeValue expr where SomeValue :: Esqueleto query expr backend => expr (Value a) -> SomeValue expr class Esqueleto (query :: * -> *) (expr :: * -> *) backend | query -> expr backend, expr -> query backend data SqlQuery a data SqlBackend data SqlExpr a where ECompositeKey :: SqlExpr (Value a) instance Esqueleto SqlQuery SqlExpr SqlBackend match' :: SomeValue SqlExpr -> a match' (SomeValue ECompositeKey) = undefined }}} On GHC 8.2.2, this typechecks without issue. On GHC 8.4.1-alpha (version 8.4.0.20180204), this fails with: {{{ $ /opt/ghc/8.4.1/bin/ghci Bug.hs GHCi, version 8.4.0.20180204: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:25:19: error: • Could not deduce: query ~ SqlQuery arising from a functional dependency between: constraint ‘Esqueleto query SqlExpr backend’ arising from a pattern with constructor: SomeValue :: forall (query :: * -> *) (expr :: * -> *) backend a. Esqueleto query expr backend => expr (Value a) -> SomeValue expr, in an equation for ‘match'’ instance ‘Esqueleto SqlQuery SqlExpr SqlBackend’ at Bug.hs:22:10-46 from the context: Value a1 ~ Value a2 bound by a pattern with constructor: ECompositeKey :: forall a. SqlExpr (Value a), in an equation for ‘match'’ at Bug.hs:25:19-31 ‘query’ is a rigid type variable bound by a pattern with constructor: SomeValue :: forall (query :: * -> *) (expr :: * -> *) backend a. Esqueleto query expr backend => expr (Value a) -> SomeValue expr, in an equation for ‘match'’ at Bug.hs:25:9-31 Inaccessible code in a pattern with constructor: ECompositeKey :: forall a. SqlExpr (Value a), in an equation for ‘match'’ • In the pattern: ECompositeKey In the pattern: SomeValue ECompositeKey In an equation for ‘match'’: match' (SomeValue ECompositeKey) = undefined | 25 | match' (SomeValue ECompositeKey) = undefined | ^^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14768: -O1 changes result at runtime, duplicating __DEFAULT case
by GHC 18 Feb '18

18 Feb '18

#14768: -O1 changes result at runtime, duplicating __DEFAULT case -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here is a program, which works as expected in GHC 8.4.1-alpha3 with `-O0`, but changes it behaviour with `-O1`. {{{#!hs {-# LANGUAGE MagicHash #-} import qualified Data.Vector.Unboxed as U import GHC.Exts vec :: U.Vector Moebius vec = U.singleton Moebius0 main :: IO () main = print $ U.head vec == U.head vec data Moebius = Moebius0 | Moebius1 | Moebius2 deriving (Eq) fromMoebius :: Moebius -> Int fromMoebius Moebius0 = 0 fromMoebius Moebius1 = 1 fromMoebius Moebius2 = 2 toMoebius :: Int -> Moebius toMoebius (I# i#) = tagToEnum# i# {- ...unboxed vector instances, see file attached... -} }}} It is expected that this program will print `True`. However, when compiled with `-O1` it prints `False`. {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.0.20180204 $ ghc -O0 Sieve.hs && ./Sieve [1 of 1] Compiling Main ( Sieve.hs, Sieve.o ) [Optimisation flags changed] Linking Sieve ... True $ ghc -O1 Sieve.hs && ./Sieve [1 of 1] Compiling Main ( Sieve.hs, Sieve.o ) [Optimisation flags changed] Linking Sieve ... False }}} It reproduces on OS X and Ubuntu, but worked fine in GHC 8.2. I looked into generated Core and found a suspicious function, having two `__DEFAULT` cases with different bodies. {{{#!hs main2 :: String main2 = case vec `cast` <Co:3> of { Vector ipv_sb7L ipv1_sb7M ipv2_sb7N -> case <# 0# ipv1_sb7M of { __DEFAULT -> case main3 ipv1_sb7M of wild_00 { }; 1# -> case indexIntArray# ipv2_sb7N ipv_sb7L of { __DEFAULT -> $fShowBool4; __DEFAULT -> $fShowBool2; 1# -> $fShowBool2; 2# -> $fShowBool2 } } } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14768> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13852: Can we have more SIMD primops, corresponding to the untapped AVX etc. instructions?
by GHC 17 Feb '18

17 Feb '18

#13852: Can we have more SIMD primops, corresponding to the untapped AVX etc. instructions? -------------------------------------+------------------------------------- Reporter: | Owner: (none) leftaroundabout | Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (LLVM) | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [http://hackage.haskell.org/package/ghc-prim-0.5.0.0/docs/GHC- Prim.html#g:28 GHC.Prim] contains a good couple of vectorised instructions, which can be [http://hackage.haskell.org/package/primitive- simd-0.1.0.0/docs/Data-Primitive-SIMD.html used by libraries] for generating nice fast e.g. sums of floating-point vectors. However, several instructions that modern processors could vectorise are missing there. In particular, I would like to be able to use the VPSLLVD...VPSRAVD shifting operations, and at some point perhaps VPMAXSQ...VPMINUQ maximum/minimum operations. It would be great if corresponding primops could be added. Else I would like to know – where is this stuff even defined? [http://hackage.haskell.org/package/ghc- prim-0.5.0.0/docs/src/GHC.Prim.html GHC.Prim] as such seems to be merely an automatically-generated dummy module, mostly for Haddock. (On the other hand, I find it also a bit strange that there are primops for [http://hackage.haskell.org/package/ghc-prim-0.5.0.0/docs/GHC- Prim.html#v:quotInt8X16-35- integer division], which is apparently [https://stackoverflow.com/questions/16822757/sse-integer-division not supported by SSE/AVX] at all!) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13852> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14782: typeclass polymorphism defeats bang patterns
by GHC 16 Feb '18

16 Feb '18

#14782: typeclass polymorphism defeats bang patterns -------------------------------------+------------------------------------- Reporter: dmwit | 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 think the following program should crash, but it doesn't: {{{ {-# LANGUAGE BangPatterns #-} main = let n :: Num a => a; !n = undefined in return () }}} Interestingly, my attempt to translate this out of BangPatterns into standard Haskell according to the translation on the wiki page led to a compile-time error: {{{ main = let n :: Num a => a; x@n = undefined in x `seq` return () }}} Produces the error: {{{ test.hs:1:12: error: • Overloaded signature conflicts with monomorphism restriction n :: forall a. Num a => a • In the expression: let n :: Num a => a x@n = undefined in x `seq` return () In an equation for ‘main’: main = let n :: Num a => a x@n = undefined in x `seq` return () | 1 | main = let n :: Num a => a; x@n = undefined in x `seq` return () | ^^^^^^^^^^^^^^^ }}} Even giving `x` its own explicitly polymorphic type signature -- what I thought was the standard way to prevent the monomorphism restriction from being a problem -- doesn't help. I'm uncertain what to make of that, but it certainly seems related: earlier versions of the compiler both do not give that error and do produce a crashing program, as I expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14782> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14814: -g causes "cc failed in phase Assembler" in yaml package
by GHC 16 Feb '18

16 Feb '18

#14814: -g causes "cc failed in phase Assembler" in yaml package -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- {{{#!bash git clone https://github.com/snoyberg/yaml cd yaml git checkout yaml-0.8.28 stack build yaml --resolver=lts-10.5 --ghc-options='-g' }}} With this I get (I'm using nix below but should be irrelevant): {{{ [nix-shell:~/programming/yaml]$ stack build yaml --nix -j1 --resolver=lts-10.5 --ghc-options='-g' raw-strings-qq-1.1: download raw-strings-qq-1.1: configure raw-strings-qq-1.1: build raw-strings-qq-1.1: copy/register Building all executables for `yaml' once. After a successful build of all of them, only specified executables will be rebuilt. yaml-0.8.28: configure (lib + exe) Configuring yaml-0.8.28... yaml-0.8.28: build (lib + exe) Preprocessing library for yaml-0.8.28.. Building library for yaml-0.8.28.. [ 1 of 10] Compiling Text.Libyaml ( Text/Libyaml.hs, .stack- work/dist/x86_64-linux-nix/Cabal-2.0.1.0/build/Text/Libyaml.o ) [ 2 of 10] Compiling Data.Yaml.Parser ( Data/Yaml/Parser.hs, .stack- work/dist/x86_64-linux-nix/Cabal-2.0.1.0/build/Data/Yaml/Parser.o ) [ 3 of 10] Compiling Data.Yaml.Internal ( Data/Yaml/Internal.hs, .stack- work/dist/x86_64-linux-nix/Cabal-2.0.1.0/build/Data/Yaml/Internal.o ) /run/user/1000/ghc25193_0/ghc_30.s: Assembler messages: /home/shana/programming/yaml//run/user/1000/ghc25193_0/ghc_30.s:67519:0: error: Error: can't resolve `.Lc1azh_entry_end' {*UND* section} - `c1azh_entry' {*UND* section} | 67519 | .quad .Lc1azh_entry_end-c1azh_entry | ^ `cc' failed in phase `Assembler'. (Exit code: 1) Progress: 1/2 -- While building custom Setup.hs for package yaml-0.8.28 using: /home/shana/.stack/setup-exe-cache/x86_64-linux-nix/Cabal- simple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 --builddir=.stack-work/dist/x86_64 -linux-nix/Cabal-2.0.1.0 build lib:yaml exe:examples exe:json2yaml exe:yaml2json --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics- color=always" Process exited with code: ExitFailure 1 Completed 2 action(s). }}} {{{ $ uname -a Linux kagami 4.14.12 #1-NixOS SMP Fri Jan 5 14:48:59 UTC 2018 x86_64 GNU/Linux }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14814> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13943: Compiler infinite loop with GHC-8.2
by GHC 15 Feb '18

15 Feb '18

#13943: Compiler infinite loop with GHC-8.2 -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 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: -------------------------------------+------------------------------------- GHC-8.0.1 compile this module in less than one seconds on my machine. Both GHC-8.2rc2 and GHC-8.2rc3 eat all 8GB of memory and don't show any signs of stopping. -dshow-passes shows this: {{{ [1 of 1] Compiling Data.List.Unrolled ( unrolled.hs, unrolled.o ) *** Parser [Data.List.Unrolled]: !!! Parser [Data.List.Unrolled]: finished in 0.00 milliseconds, allocated 3.434 megabytes *** Renamer/typechecker [Data.List.Unrolled]: }}} and then nothing. Only memory consumption grows. Code: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE GADTs #-} module Data.List.Unrolled where import GHC.TypeLits -- | Drop @n@ elements from a list class Drop (n :: Nat) where drop :: [a] -> [a] instance {-# OVERLAPPING #-} Drop 0 where drop xs = xs {-# INLINE drop #-} instance {-# OVERLAPPABLE #-} (Drop (n - 1)) => Drop n where drop [] = [] drop (_ : xs) = drop @(n - 1) xs {-# INLINE drop #-} -- | Take @n@ elements from a list class Take (n :: Nat) where take :: [a] -> [a] instance {-# OVERLAPPING #-} Take 0 where take _ = [] {-# INLINE take #-} instance {-# OVERLAPPABLE #-} (Take (n - 1)) => Take n where take [] = [] take (x : xs) = x : take @(n - 1) xs {-# INLINE take #-} -- | Split list at @n@-th element. splitAt :: forall (n :: Nat) a. (Take n, Drop n) => [a] -> ([a], [a]) splitAt xs = (take @n xs, drop @n xs) -- | Split list into chunks of the given length @c@. @n@ is length of the list. class ChunksOf (n :: Nat) (c :: Nat) where chunksOf :: [a] -> [[a]] instance {-# OVERLAPPING #-} ChunksOf 0 0 where chunksOf _ = [] {-# INLINE chunksOf #-} instance {-# OVERLAPPABLE #-} ChunksOf 0 c where chunksOf _ = [] {-# INLINE chunksOf #-} instance {-# OVERLAPPABLE #-} ChunksOf n 0 where chunksOf _ = [] {-# INLINE chunksOf #-} instance {-# OVERLAPPABLE #-} (Take c, Drop c, ChunksOf (n - 1) c) => ChunksOf n c where chunksOf xs = let (l, r) = splitAt @c xs in l : chunksOf @(n - 1) @c r {-# INLINE chunksOf #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13943> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #14790: eqTypeRep does not inline
by GHC 15 Feb '18

15 Feb '18

#14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC never seems to inline `eqTypeRep`. That's no good! It produces a `Maybe`, which users will almost certainly want to match on immediately. I really don't understand ''why'' it doesn't inline. It's a tiny function, none of the functions it calls are themselves marked `INLINE`, and the advantage to inlining seems obvious. Does the `unsafeCoerce` get in the way somehow? If so, how can we fix it? Example: {{{#!hs {-# language GADTs, ScopedTypeVariables, TypeApplications #-} module Foo where import Type.Reflection foo :: forall proxy a. Typeable a => proxy a -> Bool foo _ = case eqTypeRep (typeRep @a) (typeRep @Int) of Just _ -> True Nothing -> False }}} compiles (with `-O2`) to {{{ foo = \ (@ (proxy_a6tT :: * -> *)) (@ a_a6tU) ($dTypeable_a6tW :: Typeable a_a6tU) -> let { lvl_s6Sc :: Maybe (a_a6tU :~~: Int) [LclId] lvl_s6Sc = eqTypeRep @ * @ * @ a_a6tU @ Int ($dTypeable_a6tW `cast` (base-4.11.0.0:Data.Typeable.Internal.N:Typeable[0] <*>_N <a_a6tU>_N :: (Typeable a_a6tU :: Constraint) ~R# (TypeRep a_a6tU :: *))) Foo.foo1 } in \ _ [Occ=Dead] -> case lvl_s6Sc of { Nothing -> GHC.Types.False; Just ds1_d6Rq -> GHC.Types.True } }}} For reference, `eqTypeRep` is defined like this: {{{#!hs eqTypeRep :: forall k1 k2 (a :: k1) (b :: k2). TypeRep a -> TypeRep b -> Maybe (a :~~: b) eqTypeRep a b | typeRepFingerprint a == typeRepFingerprint b = Just (unsafeCoerce HRefl) | otherwise = Nothing }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14790> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

Re: [GHC] #6087: Join points need strictness analysis
by GHC 15 Feb '18

15 Feb '18

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > comment:12 of #5075 identifies three more tickets that claim to benefit from late-dmd-anal. Let's see if they do. One of those tickets is the current ticket. I updated #5302. I checked #6070 but late demand analysis didn't make any difference in the example functions `h` and `c` shown in the ticket. I don't know how to generated the `CPR2.c_go2`, the ticket is missing that detail. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5302: Unused arguments in join points
by GHC 15 Feb '18

15 Feb '18

#5302: Unused arguments in join points -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * Attachment "Unboxed_stock.dump-stg" added. Unboxed.hs, default -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5302> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0