November 2016 - ghc-tickets

Re: [GHC] #2721: Newtype deriving doesn't work with type families
by GHC 06 Nov '16

06 Nov '16

#2721: Newtype deriving doesn't work with type families -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 8.2.1 Component: Compiler (Type | Version: 6.10.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_fail/T2721 Blocked By: | Blocking: Related Tickets: #8165 | Differential Rev(s): Phab:D2636 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott <ryan.gl.scott@…>): In [changeset:"630d88176e8dd3ccc269451bca8f55398ef5265c/ghc" 630d8817/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="630d88176e8dd3ccc269451bca8f55398ef5265c" Allow GeneralizedNewtypeDeriving for classes with associated type families Summary: This implements the ability to derive associated type family instances for newtypes automatically using `GeneralizedNewtypeDeriving`. Refer to the users' guide additions for how this works; I essentially follow the pattern laid out in https://ghc.haskell.org/trac/ghc/ticket/8165#comment:18. Fixes #2721 and #8165. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: simonpj Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2636 GHC Trac Issues: #2721, #8165 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2721#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12691: Refine the behaviour of -dno-debug-output and -dtrace-level
by GHC 06 Nov '16

06 Nov '16

#12691: Refine the behaviour of -dno-debug-output and -dtrace-level -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | 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: -------------------------------------+------------------------------------- It wasn't clear to me what these flags should do and what they should turn off. From the user guide. `-dno-debug-output`:: Suppress any unsolicited debugging output. When GHC has been built with the DEBUG option it occasionally emits debug output of interest to developers. The extra output can confuse the testing framework and cause bogus test failures, so this flag is provided to turn it off. `-dtrace-level`:: Not present `-dno-debug-output` currently suppresses the output of `-ddump-tc-trace` which is certainly not "unsolicited". It should be used, and is, in `Outputable` to suppress the output of `pprTrace`. `dtrace-level` is used in a few places but always as if was a boolean flag. I don't really see what the point of it is. The only commit which mentions it is "8cdb98b9909561671ab4e61c90ebb12504478e4d" and I can't find the origin of the flag. I think we should just remove it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12691> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12692: Can't find interface-file decl with Typeable
by GHC 05 Nov '16

05 Nov '16

#12692: Can't find interface-file decl with Typeable -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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 attached code produces the following error: {{{ GHC error in desugarer lookup in Main: Can't find interface-file declaration for variable $tc'(,) Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): initDs IOEnv failure }}} when I run `stack bench lol`. The issue seems to be related to `Typeable` instances for types created with singletons. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12692> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12739: Failure installing elm-init-1.0.5 (ExitFailure (-6))
by GHC 05 Nov '16

05 Nov '16

#12739: Failure installing elm-init-1.0.5 (ExitFailure (-6)) --------------------------------------+--------------------------------- Reporter: rofer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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: --------------------------------------+--------------------------------- In a new directory I ran: cabal sandbox init cabal update cabal install elm-init I got the following: Resolving dependencies... Notice: installing into a sandbox located at /home/rofer/Apps/elm-init/.cabal-sandbox Downloading base-compat-0.9.1... Configuring base-unicode-symbols-0.2.2.4... Downloading binary-0.8.4.1... Configuring fail-4.9.0.0... Configuring filepath-1.4.1.0... Configuring ghc-boot-th-8.0.1... Configuring primitive-0.6.1.0... Configuring transformers-compat-0.5.1.3... Downloading pretty-1.1.3.4... Configuring base-compat-0.9.1... Downloading time-locale-compat-0.1.1.3... Configuring binary-0.8.4.1... Building base-unicode-symbols-0.2.2.4... Building fail-4.9.0.0... Building ghc-boot-th-8.0.1... Building filepath-1.4.1.0... Building primitive-0.6.1.0... Building transformers-compat-0.5.1.3... Building binary-0.8.4.1... Building base-compat-0.9.1... Installed fail-4.9.0.0 Configuring time-locale-compat-0.1.1.3... Building time-locale-compat-0.1.1.3... Configuring pretty-1.1.3.4... Installed base-unicode-symbols-0.2.2.4 Building pretty-1.1.3.4... Installed time-locale-compat-0.1.1.3 Installed filepath-1.4.1.0 Downloading directory-1.2.7.0... Configuring directory-1.2.7.0... Installed primitive-0.6.1.0 Building directory-1.2.7.0... Configuring vector-0.11.0.0... Building vector-0.11.0.0... Installed ghc-boot-th-8.0.1 Installed base-compat-0.9.1 Installed pretty-1.1.3.4 Downloading template-haskell-2.11.0.0... Configuring template-haskell-2.11.0.0... Building template-haskell-2.11.0.0... Installed directory-1.2.7.0 Configuring process-1.4.2.0... Installed transformers-compat-0.5.1.3 Building process-1.4.2.0... Installed process-1.4.2.0 Installed binary-0.8.4.1 Configuring text-1.2.2.1... Building text-1.2.2.1... Downloading template-haskell-2.11.0.0... [66/181]Configuring template-haskell-2.11.0.0... Building template-haskell-2.11.0.0... Installed directory-1.2.7.0 Configuring process-1.4.2.0... Installed transformers-compat-0.5.1.3 Building process-1.4.2.0... Installed process-1.4.2.0 Installed binary-0.8.4.1 Configuring text-1.2.2.1... Building text-1.2.2.1... Installed template-haskell-2.11.0.0 Downloading cmdargs-0.10.14... Downloading file-embed-0.0.10... Configuring file-embed-0.0.10... Downloading tagged-0.8.5... Configuring cmdargs-0.10.14... Configuring tagged-0.8.5... Building file-embed-0.0.10... Building cmdargs-0.10.14... Building tagged-0.8.5... Installed file-embed-0.0.10 Installed tagged-0.8.5 Installed cmdargs-0.10.14 Installed text-1.2.2.1 Configuring hashable-1.2.4.0... Building hashable-1.2.4.0... Installed vector-0.11.0.0 Installed hashable-1.2.4.0 Downloading nats-1.1.1... Downloading scientific-0.3.4.9... Configuring scientific-0.3.4.9... Downloading unordered-containers-0.2.7.1... Configuring nats-1.1.1... Configuring unordered-containers-0.2.7.1... Building scientific-0.3.4.9... Building nats-1.1.1... Building unordered-containers-0.2.7.1... Installed nats-1.1.1 Installed scientific-0.3.4.9 Installed unordered-containers-0.2.7.1 Downloading semigroups-0.18.2... Configuring semigroups-0.18.2... Building semigroups-0.18.2... Installed semigroups-0.18.2 Downloading attoparsec-0.13.1.0... Configuring attoparsec-0.13.1.0... Building attoparsec-0.13.1.0... Installed attoparsec-0.13.1.0 Downloading aeson-1.0.2.0... Configuring aeson-1.0.2.0... Building aeson-1.0.2.0... Installed aeson-1.0.2.0 Downloading aeson-pretty-0.8.2... Configuring aeson-pretty-0.8.2... Building aeson-pretty-0.8.2... Installed aeson-pretty-0.8.2 Downloading elm-init-1.0.5... Configuring elm-init-1.0.5... Building elm-init-1.0.5... Failed to install elm-init-1.0.5 Build log ( /home/rofer/Apps/elm-init/.cabal-sandbox/logs/elm- init-1.0.5.log ): cabal: Entering directory '/tmp/cabal-tmp-27520/elm-init-1.0.5' Configuring elm-init-1.0.5... Building elm-init-1.0.5... Preprocessing executable 'elm-init' for elm-init-1.0.5... [1 of 5] Compiling ElmInit.Util ( src/ElmInit/Util.hs, dist/dist- sandbox-7912c192/build/elm-init/elm-init-tmp/ElmInit/Util.p_o ) [2 of 5] Compiling ElmInit.Interact ( src/ElmInit/Interact.hs, dist/dist- sandbox-7912c192/build/elm-init/elm-init-tmp/ElmInit/Interact.p_o ) src/ElmInit/Interact.hs:10:1: Warning: The import of ‘<*>’ from module ‘Control.Applicative’ is redundant [3 of 5] Compiling ElmInit.Types ( src/ElmInit/Types.hs, dist/dist- sandbox-7912c192/build/elm-init/elm-init-tmp/ElmInit/Types.p_o ) src/ElmInit/Types.hs:87:1: Warning: Defined but not used: ‘emptyDecisions’ [4 of 5] Compiling ElmInit ( src/ElmInit.hs, dist/dist-sandbox- 7912c192/build/elm-init/elm-init-tmp/ElmInit.p_o ) [5 of 5] Compiling Main ( src/Main.hs, dist/dist-sandbox- 7912c192/build/elm-init/elm-init-tmp/Main.p_o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package filepath-1.4.1.0 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package unix-2.7.0.1 ... linking ... done. Loading package directory-1.2.7.0 ... linking ... done. Loading package process-1.4.2.0 ... linking ... done. Loading package ghc-boot-th-8.0.1 ... linking ... done. Loading package pretty-1.1.3.4 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package file-embed-0.0.10 ... linking ... done. Loading package base-unicode-symbols-0.2.2.4 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package fail-4.9.0.0 ... linking ... done. Loading package binary-0.8.4.1 ... linking ... done. Loading package text-1.2.2.1 ... linking ... done. Loading package hashable-1.2.4.0 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package primitive-0.6.1.0 ... linking ... done. Loading package vector-0.11.0.0 ... linking ... done. Loading package scientific-0.3.4.9 ... linking ... done. Loading package nats-1.1.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package transformers-compat-0.5.1.3 ... linking ... done. Loading package tagged-0.8.5 ... linking ... done. Loading package unordered-containers-0.2.7.1 ... linking ... done. Loading package semigroups-0.18.2 ... linking ... done. Loading package attoparsec-0.13.1.0 ... linking ... done. Loading package base-compat-0.9.1 ... linking ... done. Loading package dlist-0.7.1 ... linking ... done. Loading package time-locale-compat-0.1.1.3 ... linking ... done. Loading package aeson-1.0.2.0 ... linking ... done. Loading package aeson-pretty-0.8.2 ... linking ... done. ghc: internal error: stg_ap_pp_ret (GHC version 7.8.4 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Leaving directory '/tmp/cabal-tmp-27520/elm-init-1.0.5' cabal: Error: some packages failed to install: elm-init-1.0.5 failed during the building phase. The exception was: ExitFailure (-6) I'm on Fedora 23 (4.7.6-100.fc23.x86_64). Let me know if you need anything else. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12806: curl dependency in conjunction with Template Haskell causes "unknown symbol" errors
by GHC 05 Nov '16

05 Nov '16

#12806: curl dependency in conjunction with Template Haskell causes "unknown symbol" errors -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've reported on this issue to the stack issue tracker here https://github.com/commercialhaskell/stack/issues/2752#issuecomment-2573785… The steps to reproduce are the following * Make a new stack project (lts-5.3 in my case). stack new curl-test -resolver=lts-5,3 * Add curl as a dependency to the library. * Modify the Lib file to the following {{{ {-# LANGUAGE TemplateHaskell #-} module Lib where return [] someFunc :: IO () someFunc = return () }}} The error that I get with GHC 8 is this {{{ ghc.EXE: unable to load package `curl-1.3.8' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `stricmp' ghc.EXE: Could not on-demand load symbol 'curl_strequal' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `curl_strequal' ghc.EXE: Could not on-demand load symbol '.refptr.Curl_cstrdup' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `.refptr.Curl_cstrdup' ghc.EXE: Could not on-demand load symbol 'curl_slist_free_all' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `curl_slist_free_all' ghc.EXE: Could not on-demand load symbol 'Curl_ssl_connect_nonblocking' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `Curl_ssl_connect_nonblocking' ghc.EXE: Could not on-demand load symbol '.refptr.Curl_crealloc' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `.refptr.Curl_crealloc' ghc.EXE: Could not on-demand load symbol 'curl_msnprintf' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `curl_msnprintf' ghc.EXE: Could not on-demand load symbol '.refptr.Curl_cmalloc' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `.refptr.Curl_cmalloc' ghc.EXE: Could not on-demand load symbol 'Curl_verify_windows_version' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `Curl_verify_windows_version' ghc.EXE: Could not on-demand load symbol 'Curl_sspi_global_init' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `Curl_sspi_global_init' ghc.EXE: Could not on-demand load symbol 'curl_global_init' ghc.EXE: C:\sr\snapshots\df48cbae\lib\x86_64-windows- ghc-8.0.1\curl-1.3.8-B8AxMCtSRkiFrZLK4gerBe\HScurl-1.3.8-B8AxMCtSRkiFrZLK4gerBe.o: unknown symbol `curl_global_init' }}} but this still fails with GHC 7.10.3 with a similar error. This is happening on two Windows 10 machines so it's not an isolated case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12806> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11571: Need more intelligent conditionalization of libgcc rts symbols for x32
by GHC 05 Nov '16

05 Nov '16

#11571: Need more intelligent conditionalization of libgcc rts symbols for x32 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: Other | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In `rts/RtsSymbols.c` we have {{{ // 64-bit support functions in libgcc.a #if defined(__GNUC__) && SIZEOF_VOID_P <= 4 && !defined(_ABIN32) #define RTS_LIBGCC_SYMBOLS \ SymI_NeedsProto(__divdi3) \ SymI_NeedsProto(__udivdi3) \ ... }}} The purpose is to provide these symbols to `.o` files that use these symbols, expecting to be linked against libgcc. These symbols are for things like 64-bit integer division that aren't available as machine instructions on some platforms. But the `#if` is wrong on x32, which, despite having `sizeof(void *) == 4`, naturally has a full complement of 64-bit arithmetic instructions, since its registers are 64 bits wide. So libgcc does not provide these symbols, and as a result we eventually encounter missing symbol errors when linking the rts. Some possible solutions include * Figure out if there is a CPP variable set for x32 and don't include these symbols if that variable is set. I'm not sure whether `__ILP32__` is such a variable (after all x86 is also an architecture on which int, long and pointers are 32-bits). * Use autoconf to detect the presence of these symbols in libgcc. (Probably just pick one, like `__divdi3`, and hope they are all present or all missing.) * Use weak symbols somehow to add these symbols to the RTS's internal symbol table if and only if the RTS was linked against a libgcc that provides these symbols. My Android ghci also needs lots more of these, including `__modsi3`, `__umodsi3`, `__ctzdi2`, a bunch of `__aeabi_*` and `__sync_*`, and `__sF` (no idea what that is). So I'm inclined towards the last option. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11571> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12539: Possible typo causes Stack and Cabal installs to fail
by GHC 04 Nov '16

04 Nov '16

#12539: Possible typo causes Stack and Cabal installs to fail -------------------------------------+------------------------------------- Reporter: ConorIA | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, I have been trying to use https://github.com/thriqon/pandoc-docker or to add pandoc to https://github.com/mitchty/alpine-ghc. However, in both cases, install commands are running into an issue with the '-nopie' flag passed to GCC. The gist of the error thrown when using wither Cabal or Stack is: {{{ <no location info>: Warning: Couldn't figure out linker information! Make sure you're using GNU ld, GNU gold or the built in OS X linker, etc. gcc: error: unrecognized command line option '-nopie'; did you mean '-no- pie'? ) }}} I am not sure where the error is, as I am really a non-expert. But the gcc linking option is "-no-pie", so if there is indeed an option "-nopie" being passed, it seems like it is a typo. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12539> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7606: Stride scheduling for Haskell threads with priorities
by GHC 04 Nov '16

04 Nov '16

#7606: Stride scheduling for Haskell threads with priorities -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): No new progress since my last comment! Perhaps we should resurrect this patchset. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7606#comment:46> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12804: forever contains a space leak
by GHC 04 Nov '16

04 Nov '16

#12804: forever contains a space leak -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- 4.9.0.0's `forever` (implemented in terms of `Applicative`) has a space leak for certain base `Monad`s. The old `forever` (implemented in terms of `Monad`) does not. See these messages for details * https://mail.haskell.org/pipermail/haskell-cafe/2016-October/125177.html * https://mail.haskell.org/pipermail/haskell-cafe/2016-October/125178.html * https://mail.haskell.org/pipermail/haskell- cafe/2016-November/125443.html This is not necessarily `forever`'s fault. It seems likely that the broken behaviour that occurs with `ReaderT` and `StateT` (on `IO`) could be fixed by a specialised implementation of `*>` (for `ReaderT` and `StateT`). Perhaps, then, this bug should ultimately be fixed in `transformers` (and various other packages which supply `Applicative`s) but it is a regression introduced by base-4.9.0.0 so I think it's worthwhile to discuss here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12804> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7606: Stride scheduling for Haskell threads with priorities
by GHC 04 Nov '16

04 Nov '16

#7606: Stride scheduling for Haskell threads with priorities -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) Comment: Edward, BTW what's the state of this? The last set of numbers look not too bad at all. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7606#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0