February 2014 - ghc-tickets

[GHC] #8776: Displaying pattern synonym for a GADT
by GHC 23 Mar '14

23 Mar '14

#8776: Displaying pattern synonym for a GADT ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Define {{{ {-# LANGUAGE PatternSynonyms, GADTs #-} data A x y where B :: A x x pattern P = B }}} and in GHCi we see {{{ λ> :i P pattern (t ~ t) => P :: A t t1 -- Defined at X.hs:5:9 }}} It should be `(t ~ t1)`. Just a problem with displaying, the pattern works correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8776> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8649: Disambiguate Repeated Identifiers for data types in error messages
by GHC 23 Mar '14

23 Mar '14

#8649: Disambiguate Repeated Identifiers for data types in error messages ------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If, in an interactive context, you redefine a type, but then try to use functions for the previous definition, it will (as expected) give you an error message. The following code would trigger this in an interactive context: {{{ data X = Y Int f (Y i) = i data X = Y Int | Z String f (Y 3) }}} However the error message is not very good: {{{ Couldn't match expected type `:Interactive.X' with actual type `:Interactive.X' }}} This is very uninformative to the user if they do not understand what's going on. The following GHC API code can replicate this: {{{ runDeclsWithLocation "Interactive.hs" 1 "data X = Y Int" runDeclsWithLocation "Asdf.hs" 2 "f (Y i) = i" runDeclsWithLocation "Bloop.hs" 3 "data X = Y Int | Z String" runStmtWithLocation "Test.hs" 4 "f (Y 3)" RunToCompletion }}} Note that varying the location given to `runStmt` and `runDecls` (the string as well as the line number) seems to have no effect upon anything. I started out with just "<interactive>" but varied it to check - no effect on anything as far as I can tell. How can I make this error message more informative? I would ideally like something like {{{ Couldn't match expected type `:Interactive1.X' with actual type `:Interactive5.X' }}} or really anything that caused these types to be visibly different. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8649> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8351: Arrays are always allocated out-of-line
by GHC 23 Mar '14

23 Mar '14

#8351: Arrays are always allocated out-of-line ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- unordered-containers uses lots of small arrays (length <= 16). These arrays are always allocated out-of-line by a call to `allocate`. I suspect this is bad for performance. We should look into supporting inline- allocation, perhaps by using a new `newSmallArray#` primop and/or by spotting calls to `newArray#` with a small, statically-known size. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8351> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8765: Add --with-ar and --with-ranlib configure params.
by GHC 22 Mar '14

22 Mar '14

#8765: Add --with-ar and --with-ranlib configure params. ------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've found that I usually miss --with-ar and/or --with-ranlib on Solaris while building GHC. Attached patch fixes that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8765> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8600: ghc --help is outdated
by GHC 22 Mar '14

22 Mar '14

#8600: ghc --help is outdated ------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- {{{ To compile and link a complete Haskell program, run the compiler like so: ghc --make Main where the module Main is in a file named Main.hs (or Main.lhs) in the current directory. The other modules in the program will be located and compiled automatically, and the linked program will be placed in the file `a.out' (or `Main.exe' on Windows). }}} First, --make is no longer necessary. Second, ghc doesn't create a.out on Unix — instead, the file is named the same as the main module (Main in that example). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8738: msys2 fails cabal01 test
by GHC 22 Mar '14

22 Mar '14

#8738: msys2 fails cabal01 test --------------------------+------------------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Test | Version: 7.8.1-rc1 Suite | Operating System: Windows Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: cabal01 Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ msys2 with 64-bit GHC has an odd failure here: {{{ =====> cabal01(normal) 81 of 3859 [0, 0, 0] cd ./cabal/cabal01 && $MAKE -s --no-print-directory cabal01 VANILLA =--enable-library-vanilla PROF=--disable-library-profiling DYN=--disable- shared </dev/null >cabal01.run.stdout 2>cabal01.run.stderr Actual stdout output differs from expected: --- ./cabal/cabal01/cabal01.stdout-mingw32 2014-02-02 04:48:11.233000000 +0000 +++ ./cabal/cabal01/cabal01.run.stdout 2014-02-05 03:09:28.998400000 +0000 @@ -1,9 +1,9 @@ install1: bin -test-1.0 +x86_64-windows-ghc-7.9.20140205 install2: bin -test-1.0 +x86_64-windows-ghc-7.9.20140205 dist: build package.conf.inplace }}} This is because setup is selecting this directory as the location for the installation: {{{ /inplace/bin/ghc-pkg.exe' --package- db=local.db'C:/msys64/home/Administrator/ghc Configuring test-1.0... Warning: No 'build-type' specified. If you do not need a custom Setup.hs or ./configure script then use 'build-type: Simple'. Dependency base >=1.0: using base-4.7.0.0 "C:/msys64/home/Administrator/ghc/inplace/bin/ghc-stage2.exe" "--info" Using Cabal-1.18.1.3 compiled by ghc-7.9 Using compiler: ghc-7.9.20140205 Using install prefix: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install Binaries installed in: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin Libraries installed in: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0 Private binaries installed in: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\test-1.0 Data files installed in: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0 Documentation installed in: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\doc\x86_64 -windows-ghc-7.9.20140205\test-1.0 Configuration files installed in: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\etc Administrator@EZYANG-W2K8 ~/ghc/testsuite/tests/cabal/cabal01 $ ./setup.exe copy -v directory dist\doc\html\test does exist: False Installing library in C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0 Installing executable(s) in C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin Warning: The directory C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin is not in the system search path. creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205\test-1.0 creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205 creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205 creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205\test-1.0 creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205\test-1.0\B Installing dist\build\A.hi to C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0\A.hi Installing dist\build\B\A.hi to C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0\B\A.hi creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205\test-1.0 Installing dist\build\libHStest-1.0.a to C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0\libHStest-1.0.a creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205\test-1.0 Installing dist\build\HStest-1.0.o to C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0\HStest-1.0.o creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\bin Installing executable dist\build\testA\testA.exe to C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin\testA.exe C:\msys64\ghc-7.6.3\mingw\bin\strip.exe C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin\testA.exe creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\bin Installing executable dist\build\testB\testB.exe to C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin\testB.exe C:\msys64\ghc-7.6.3\mingw\bin\strip.exe C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin\testB.exe }}} Perhaps a cabal developer can stare at the relevant codepath and figure out why this directory name is being selected? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8738> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8693: dyn way broken on powerpc
by GHC 20 Mar '14

20 Mar '14

#8693: dyn way broken on powerpc ----------------------------+---------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: powerpc | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------------- Building GHC with dynamic enabled I see lots of the following errors on powerpc (32 bit): {{{ [ 1679s] /tmp/ghc19669_0/ghc19669_6.s: Assembler messages: [ 1679s] [ 1679s] /tmp/ghc19669_0/ghc19669_6.s:39625:0: [ 1679s] Error: operand out of range (0x000000000000b700 is not between 0xffffffffffff8000 and 0x0000000000007fff) ... [ 1679s] /tmp/ghc19669_0/ghc19669_6.s:43936:0: [ 1679s] Error: operand out of range (0x0000000000008018 is not between 0xffffffffffff8000 and 0x0000000000007fff) [ 1679s] make[1]: *** [libraries/time/dist- install/build/Data/Time/Format.o] Error 1 [ 1679s] make[1]: *** Deleting file `libraries/time/dist- install/build/Data/Time/Format.o' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8693> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8164: GHC HEAD panics in testsuite on OS X 10.8 with cc=Clang (using newest xcode 5 dev tools)
by GHC 17 Mar '14

17 Mar '14

#8164: GHC HEAD panics in testsuite on OS X 10.8 with cc=Clang (using newest xcode 5 dev tools) ----------------------------------+--------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- I got the following panics when I ran the GHC test suite per ticket #8148 (using xcode 5 CLI dev preview tools released as of august 21st on OS X 10.8) =====> ghcilink003(normal) 889 of 3736 [8, 195, 0] cd ./ghci/linking && $MAKE -s --no-print-directory ghcilink003 </dev/null >ghcilink003.run.stdout 2>ghcilink003.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): Loading archives not supported Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> EnumFromToP(normal) 564 of 3736 [0, 82, 0] cd ./dph/enumfromto && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c EnumFromToP.hs -O -fno-enable-rewrite-rules -package dph-lifted-vseg >EnumFromToP.comp.stderr 2>&1 Actual stderr output differs from expected: --- /dev/null 2013-08-22 16:09:56.000000000 -0400 +++ ./dph/enumfromto/EnumFromToP.comp.stderr 2013-08-22 16:11:18.000000000 -0400 @@ -0,0 +1,6 @@ +ghc-stage2: panic! (the 'impossible' happened) + (GHC version 7.7.20130822 for x86_64-apple-darwin): + DsMonad: uninitialised ds_parr_bi + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> jmp_tbl(optasm) 102 of 3736 [0, 33, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c jmp_tbl.hs -O -fasm -fPIC -O >jmp_tbl.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> T7574(hpc) 102 of 3736 [0, 33, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7574.cmm -O -fhpc -hpcdir .hpc.T7574 -no- hs-main >T7574.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> T7574(optasm) 102 of 3736 [0, 33, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7574.cmm -O -fasm -no-hs-main >T7574.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> T7574(normal) 102 of 3736 [0, 2, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7574.cmm -no-hs-main >T7574.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8164> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8826: Allow more coercions in Safe Haskell
by GHC 17 Mar '14

17 Mar '14

#8826: Allow more coercions in Safe Haskell ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Suppose we have {{{ newtype Age = MkAge Int }}} and we have `m :: Map String Int`. Is `coerce m :: Map String Age` allowed in Safe Haskell? Currently, no, because of the need to have `Map`'s constructor visible at the cite of the coercion. Why do we need this? In order to forestall any possible abstraction breaking. See [https://ghc.haskell.org/trac/ghc/ticket/8745#comment:3 this comment] for more information. But, it would seem that if the writer of `Map` supplies a role annotation, all should be forgiven. The author of the data structure is saying, with `type role Map nominal representational` that it is OK to coerce the second parameter. The annotation means that the author has considered roles and knows what the roles imply. So, I propose this: We allow coercions in Safe Haskell when the following algorithm permits it (and if the coercion is otherwise type-safe): Traverse down the tree of datatype definitions starting at the datatype to be coerced. At every datatype use, check if that datatype has a role annotation. If so, permit the coercion. Otherwise, require all constructors of the datatype to be in scope and recur on any datatypes mentioned in those constructors. Under that algorithm, we quickly discover that `Map` has a role annotation and permit (type-safe) coercions straightaway. This proposal is strictly a loosening of the current rules, and would allow strictly more programs to be accepted as Safe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8826> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error
by GHC 17 Mar '14

17 Mar '14

#8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error ----------------------------------+------------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- The attached program produces an core lint error when compiling with optimization. {{{ $ ghc -O -debug -dcore-lint Main [1 of 1] Compiling Main ( Main.hs, Main.o ) *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}) *** <no location info>: Warning: In the type ‛cache_s16y’ @ cache_s16y is out of scope *** Offending Program *** Main.focusAst :: forall syntax_aB4. GHC.Types.Int -> Main.BufferImpl syntax_aB4 -> Main.BufferImpl syntax_aB4 [LclIdX, Arity=2, Str=DmdType <L,U><S(S),1*U(U)>m, Unf=Unf{Src=InlineStable, TopLvl=True, Arity=2, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=False) Tmpl= \ (@ syntax_aMw) (r_aB5 [Occ=Once] :: GHC.Types.Int) (b_aB6 [Occ=Once!] :: Main.BufferImpl syntax_aMw) -> case b_aB6 of _ [Occ=Dead, Dmd=<L,A>] { Main.FBufferData ds_dOP [Occ=Once!, Dmd=<S,U>] -> case ds_dOP of _ [Occ=Dead, Dmd=<L,A>] { Main.HLState @ cache_s16y dt_s16z [Dmd=<C(C(S)),U>] cache_s16A [Occ=Once, Dmd=<S,U>] -> case dt_s16z r_aB5 cache_s16A of dt_XBQ { __DEFAULT -> Main.FBufferData @ syntax_aMw (Main.HLState @ syntax_aMw @ cache_s16y dt_s16z dt_XBQ) } } }}] Main.focusAst = \ (@ syntax_aMw) (r_aB5 :: GHC.Types.Int) (b_aB6 :: Main.BufferImpl syntax_aMw) -> case b_aB6 of _ [Occ=Dead, Dmd=<L,A>] { Main.FBufferData ds_dOP [Dmd=<S,U>] -> case ds_dOP of _ [Occ=Dead] { Main.HLState @ cache_s220 dt_s221 cache_s222 -> case dt_s221 r_aB5 cache_s222 of dt_XBQ { __DEFAULT -> Main.FBufferData @ syntax_aMw (Main.HLState @ syntax_aMw @ cache_s220 dt_s221 dt_XBQ) } } } <snip> }}} The full log is attached. The same error occurs with a GHC HEAD build from 2012/12/12. I will check with a latest HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15