February 2018 - ghc-tickets

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): Now that I understand ticky profiling better I also took another look at `cse` again. The difference is is these two functions: {{{ Entries Alloc Alloc'd Non-void Arguments STG Name -------------------------------------------------------------------------------- 524 12072 0 2 Li $wgo1{v r6T8} (main:Main) (fun) 394 9984 0 2 LL $wdraw{v r6Tg} (main:Main) (fun) total: 918 22056 }}} after late demand analysis this becomes: {{{ Entries Alloc Alloc'd Non-void Arguments STG Name -------------------------------------------------------------------------------- 524 11424 0 2 Li $w$wgo{v r71J} (main:Main) (fun) 394 12768 0 2 LL $wdraw{v r71R} (main:Main) (fun) total: 918 24192 }}} Definitions: (common parts in `wdraw` functions removed) {{{ $wgo1_r6T8 :: [GHC.Types.Char] -> GHC.Prim.Int# -> [GHC.Types.Char] [GblId, Arity=2, Str=<S,1*U><S,1*U>m2, Unf=OtherCon []] = sat-only [] \r [w_s6XW ww_s6XX] case w_s6XW of { [] -> $wxs1_r6T7 ww_s6XX; : y_s6XZ [Occ=Once*] ys_s6Y0 [Occ=Once] -> case ww_s6XX of ds11_s6Y1 { __DEFAULT -> let { sat_s6Y3 [Occ=Once] :: [GHC.Types.Char] [LclId] = [ys_s6Y0 ds11_s6Y1] \u [] case -# [ds11_s6Y1 1#] of sat_s6Y2 { __DEFAULT -> $wgo1_r6T8 ys_s6Y0 sat_s6Y2; }; } in : [y_s6XZ sat_s6Y3]; 1# -> : [y_s6XZ n_r6T1]; }; }; $wdraw_r6Tg :: [GHC.Types.Char] -> [Main.GenTree [GHC.Types.Char]] -> [[GHC.Types.Char]] [GblId, Arity=2, Str=<L,1*U><S,1*U>, Unf=OtherCon []] = sat-only [] \r [ww_s6ZI ww1_s6ZJ] let { sat_s70m [Occ=Once, Dmd=<L,1*U>] :: [GHC.Types.Char] [LclId] = [ww_s6ZI] \s [] let { sat_s70l [Occ=Once, Dmd=<L,1*U>] :: [GHC.Types.Char] [LclId] = [ww_s6ZI] \s [] $wgo1_r6T8 ww_s6ZI 4#; } in GHC.Base.++ ds10_r6SZ sat_s70l; } in case case ww1_s6ZJ of { [] -> lvl23_r6Tc; : t_s6ZL [Occ=Once*!] ds11_s6ZM [Occ=Once!] -> case ds11_s6ZM of { [] -> case case t_s6ZL of { Main.Node ww3_s6ZP [Occ=Once] ww4_s6ZQ [Occ=Once] -> $wdraw_r6Tg ww3_s6ZP ww4_s6ZQ; } of sat_s6ZR { __DEFAULT -> $sgo1_r6SJ sat_s6ZR ds9_r6SX xs2_r6Tf; }; : ipv_s6ZS [Occ=Once] ipv1_s6ZT [Occ=Once] -> let { z_s6ZU [Occ=OnceL] :: [[GHC.Types.Char]] [LclId] = [ipv_s6ZS ipv1_s6ZT] \u [] $srsLoop_r6Th ipv_s6ZS ipv1_s6ZT; } in let { z1_s6ZV :: [[GHC.Types.Char]] [LclId, Unf=OtherCon []] = CCCS :! [ds5_r6SS z_s6ZU]; } in let { go4_s6ZX [Occ=LoopBreaker] :: [[GHC.Types.Char]] -> [[GHC.Types.Char]] -> [[GHC.Types.Char]] } in let { $sgo6_s6ZW [Occ=Once!T[3]] :: [[GHC.Types.Char]] -> [GHC.Types.Char] -> [[GHC.Types.Char]] -> [[GHC.Types.Char]] } in case case t_s6ZL of { Main.Node ww3_s70h [Occ=Once] ww4_s70i [Occ=Once] -> $wdraw_r6Tg ww3_s70h ww4_s70i; } of sat_s70j { __DEFAULT -> $sgo6_s6ZW sat_s70j ds7_r6SV xs_r6ST; }; }; } of sat_s70k { __DEFAULT -> $sgo2_r6SH sat_s70k sat_s70m xs1_r6T5; }; }}} after late demand analysis: {{{ $w$wgo_r71J :: [GHC.Types.Char] -> GHC.Prim.Int# -> (# GHC.Types.Char, [GHC.Types.Char] #) [GblId, Arity=2, Str=<S,1*U><S,1*U>, Unf=OtherCon []] = sat-only [] \r [w_s76A w1_s76B] case w_s76A of { [] -> $w$wxs_r71I w1_s76B; : y_s76D [Occ=Once*] ys_s76E [Occ=Once] -> case w1_s76B of ds11_s76F { __DEFAULT -> let { sat_s76K [Occ=Once] :: [GHC.Types.Char] [LclId] = [ys_s76E ds11_s76F] \u [] case -# [ds11_s76F 1#] of sat_s76G { __DEFAULT -> case $w$wgo_r71J ys_s76E sat_s76G of { (#,#) ww1_s76I [Occ=Once] ww2_s76J [Occ=Once] -> : [ww1_s76I ww2_s76J]; }; }; } in (#,#) [y_s76D sat_s76K]; 1# -> (#,#) [y_s76D n_r71D]; }; }; $wdraw_r71R :: [GHC.Types.Char] -> [Main.GenTree [GHC.Types.Char]] -> [[GHC.Types.Char]] [GblId, Arity=2, Str=<L,1*U><S,1*U>, Unf=OtherCon []] = sat-only [] \r [ww_s78p ww1_s78q] let { karg_s78r [Occ=Once*, Dmd=<L,1*U>] :: [GHC.Types.Char] [LclId] = [ww_s78p] \s [] let { sat_s78v [Occ=Once, Dmd=<L,1*U>] :: [GHC.Types.Char] [LclId] = [ww_s78p] \s [] case $w$wgo_r71J ww_s78p 4# of { (#,#) ww3_s78t [Occ=Once] ww4_s78u [Occ=Once] -> : [ww3_s78t ww4_s78u]; }; } in GHC.Base.++ ds10_r71B sat_s78v; } in case ww1_s78q of { [] -> $sgo2_r71j lvl22_r71N karg_s78r xs1_r71H; : t_s78x [Occ=Once*!] ds11_s78y [Occ=Once!] -> case ds11_s78y of { [] -> case t_s78x of { Main.Node ww3_s78B [Occ=Once] ww4_s78C [Occ=Once] -> case $wdraw_r71R ww3_s78B ww4_s78C of sat_s78D { __DEFAULT -> case $sgo1_r71l sat_s78D ds9_r71z xs2_r71Q of sat_s78E { __DEFAULT -> $sgo2_r71j sat_s78E karg_s78r xs1_r71H; }; }; }; : ipv_s78F [Occ=Once!] ipv1_s78G [Occ=Once] -> let { z_s78H [Occ=OnceL] :: [[GHC.Types.Char]] [LclId] = [ipv_s78F ipv1_s78G] \u [] case ipv_s78F of { Main.Node ww3_s78J [Occ=Once] ww4_s78K [Occ=Once] -> $w$srsLoop_r71S ww3_s78J ww4_s78K ipv1_s78G; }; } in let { z1_s78L :: [[GHC.Types.Char]] [LclId, Unf=OtherCon []] = CCCS :! [ds5_r71u z_s78H]; } in let { go4_s78N [Occ=LoopBreaker] :: [[GHC.Types.Char]] -> [[GHC.Types.Char]] -> [[GHC.Types.Char]] } in let { $sgo6_s78M [Occ=Once!] :: [[GHC.Types.Char]] -> [GHC.Types.Char] -> [[GHC.Types.Char]] -> [[GHC.Types.Char]] } in case t_s78x of { Main.Node ww3_s797 [Occ=Once] ww4_s798 [Occ=Once] -> case $wdraw_r71R ww3_s797 ww4_s798 of sat_s799 { __DEFAULT -> case $sgo6_s78M sat_s799 ds7_r71x xs_r71v of sat_s79a { __DEFAULT -> $sgo2_r71j sat_s79a karg_s78r xs1_r71H; }; }; }; }; }; }}} Somehow new `wdraw` function should be doing more allocation but I couldn't figure how yet. Also attached the whole STG dumps. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14807: GHC does not pass -dstg-lint
by GHC 15 Feb '18

15 Feb '18

#14807: GHC does not pass -dstg-lint -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When building ghc-8.4 branch with -dstg-lint enabled I got a GHC panic error (please see attachment as it's really big). The error is reproducible on Windows and Debian Linux 64 bit operating systems. As a side note, it seems that it would be good to enable `-dstg-lint` and `-dcmm-lint` in `devel2` flavour, and possibly some other flavours, or at least on CI, so that they will be tested more frequently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14807> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4505: Segmentation fault on long input (list of pairs)
by GHC 14 Feb '18

14 Feb '18

#4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * priority: high => normal Comment: given that it works compiled with -O this doesn't seem high priority. If anybody disagrees feel free to raise the priority back to high -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8258: GHC accepts `data Foo where` in H2010 mode
by GHC 14 Feb '18

14 Feb '18

#8258: GHC accepts `data Foo where` in H2010 mode --------------------------+------------------------------------------------ Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 7.8.1 Component: | Version: 7.0.4 Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC accepts invalid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ According to the Haskell2010 report, The grammar productions relevant for `data` declarations are the following: {{{ topdecl → data [context =>] simpletype [= constrs] [deriving] }}} (from [http://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-680004.2 4.2.1 Algebraic Datatype Declarations]) However, GHC 7.0.4/7.4.2/7.6.3/HEAD all happily compile the following Haskell module without any warning when using `-XHaskell2010 -Wall`, even though this is not valid Haskell2010 afaik: {{{#!hs module Foo where data Foo where }}} The trailing `where` in the `data` declaration is not valid Haskell2010 (without language extensions such as `GADT`). At the very least, this divergence from the Haskell Report should be mentioned in [http://www.haskell.org/ghc/docs/latest/html/users_guide /bugs-and-infelicities.html#haskell-standards-divergence 14.1.1. Divergence from Haskell 98 and Haskell 2010]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8258> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 14 Feb '18

14 Feb '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: Nor for 8.4.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

14 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): > cse and circsim really do allocate (a little) more. But in your investigation you didn't find any allocation differences. Doesn't -ticky nail it for you? Just compared original vs. late demand analysis version of the same function in mate with help from ticky profiler and found the source of allocation. (the function is huge, copying the important bits. Both functions have same number of entries) Original function, important bit is how the second argument (Int) used: {{{ $warg_sciK [InlPrag=NOUSERINLINE[0], Occ=OnceL*!, Dmd=<L,C(C1(C1(C1(U))))>] :: Board.Kind -> GHC.Types.Int -> GHC.Types.Int -> GHC.Types.Bool -> GHC.Types.Bool [LclId, Arity=4, Str=<S,1*U><S(S),U(U)><L,U(U)><L,1*U>, Unf=OtherCon []] = sat-only [w_scin ww_scio ww1_scip ds_sciq lvl17_scis lvl18_sciB] \r [ww2_sciL ww3_sciM ww4_sciN w1_sciO] let { lvl19_sciP [Occ=Once*!, Dmd=<L,1*U>] :: GHC.Types.Bool [LclId] = [ww_scio ww1_scip ds_sciq ww3_sciM] \s [] let { lvl20_sciQ [Occ=OnceL*!, Dmd=<L,U(U)>] :: GHC.Types.Int [LclId] = [ds_sciq ww3_sciM] \u [] case ww3_sciM of wild_sciR { GHC.Types.I# x1_sciS [Occ=Once] -> case ds_sciq of { (,) xk_sciU [Occ=Once!] _ [Occ=Dead] -> case xk_sciU of wild2_sciW { GHC.Types.I# y1_sciX [Occ=Once] -> case <=# [x1_sciS y1_sciX] of { __DEFAULT -> wild_sciR; 1# -> wild2_sciW; }; }; }; }; } in let { lvl21_sciZ [Occ=OnceL*!, Dmd=<L,U(U)>] :: GHC.Types.Int [LclId] = [ds_sciq ww3_sciM] \u [] case ww3_sciM of wild_scj0 { GHC.Types.I# x1_scj1 [Occ=Once] -> case ds_sciq of { (,) xk_scj3 [Occ=Once!] _ [Occ=Dead] -> case xk_scj3 of wild2_scj5 { GHC.Types.I# y1_scj6 [Occ=Once] -> case <=# [x1_scj1 y1_scj6] of { __DEFAULT -> wild2_scj5; 1# -> wild_scj0; }; }; }; }; } in ... }}} It's used strictly, but also returned in boxed form in `__DEFAULT` case of first case expression and `1#` case of the second. Now with late demand analysis: {{{ $w$warg_sd96 [InlPrag=NOUSERINLINE[0], Occ=OnceL*!, Dmd=<L,C(C1(C1(C1(U))))>] :: Board.Kind -> GHC.Prim.Int# -> GHC.Types.Int -> GHC.Types.Bool -> GHC.Types.Bool [LclId, Arity=4, Str=<S,1*U><S,U><L,U(U)><L,1*U>, Unf=OtherCon []] = sat-only [w_sd8J ww_sd8K ww1_sd8L ds_sd8M lvl17_sd8O lvl18_sd8X] \r [w1_sd97 ww2_sd98 w2_sd99 w3_sd9a] let { ww3_sd9b [Dmd=<L,U(U)>] :: GHC.Types.Int [LclId, Unf=OtherCon []] = CCCS GHC.Types.I#! [ww2_sd98]; } in let { lvl19_sd9c [Occ=Once*!, Dmd=<L,1*U>] :: GHC.Types.Bool [LclId] = [ww_sd8K ww1_sd8L ds_sd8M ww2_sd98 ww3_sd9b] \s [] let { lvl20_sd9d [Occ=OnceL*!, Dmd=<L,U(U)>] :: GHC.Types.Int [LclId] = [ds_sd8M ww2_sd98 ww3_sd9b] \u [] case ds_sd8M of { (,) xk_sd9f [Occ=Once!] _ [Occ=Dead] -> case xk_sd9f of wild1_sd9h { GHC.Types.I# y1_sd9i [Occ=Once] -> case <=# [ww2_sd98 y1_sd9i] of { __DEFAULT -> ww3_sd9b; 1# -> wild1_sd9h; }; }; }; } in let { lvl21_sd9k [Occ=OnceL*!, Dmd=<L,U(U)>] :: GHC.Types.Int [LclId] = [ds_sd8M ww2_sd98 ww3_sd9b] \u [] case ds_sd8M of { (,) xk_sd9m [Occ=Once!] _ [Occ=Dead] -> case xk_sd9m of wild1_sd9o { GHC.Types.I# y1_sd9p [Occ=Once] -> case <=# [ww2_sd98 y1_sd9p] of { __DEFAULT -> wild1_sd9o; 1# -> ww3_sd9b; }; }; }; } in ... }}} now the second argument is `Int#` instead of `Int` as before, but we pack it in the first `let` because we need to return it boxed (`_DEFAULT` case of first case expression and `1#` case of the second case). This is the only extra source of allocation in mate as far as I can see from the ticky output so this should be responsible for 5% increase in `mate`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14810: Define MVar "This function is atomic only if there are no other producers for this MVar."
by GHC 14 Feb '18

14 Feb '18

#14810: Define MVar "This function is atomic only if there are no other producers for this MVar." -------------------------------------+------------------------------------- Reporter: akfp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The sentence: This function is atomic only if there are no other producers for this MVar. Is repeated lots of times in the Control.Concurrent.MVar documentation. However, there is no definition of what "producers for an MVar" means. There needs to be a definition of producer (and consumer I guess). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14810> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9269: Type families returning quantified types
by GHC 14 Feb '18

14 Feb '18

#9269: Type families returning quantified types ------------------------------------+------------------------------------- Reporter: pumpkin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Is there a fundamental reason for not being able to use quantification in a type family? I'd very much like to be able to do it, obviously turning on RankNTypes if necessary. I'm looking for things like this: {{{#!haskell type family Foo (x :: Bool) where Foo True = forall a. [a] Foo False = () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9269> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12422: Add decidable equality class
by GHC 14 Feb '18

14 Feb '18

#12422: Add decidable equality class -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | 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: -------------------------------------+------------------------------------- Currently, we have a `TestEquality` class {{{#!hs class TestEquality f where testEquality :: f a -> f b -> Maybe (a :~: b) }}} It would be nice to add a class for fully decidable equality. There are a few options, but this one gets to the point rather quickly: {{{#!hs data EqDec a b where NotEqual :: (forall c . a :~: b -> c) -> EqDec a b Equal :: EqDec a a class DecEq f where decEq :: f a -> f b -> EqDec a b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12422> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14809: Invocation of ghc with --make flag should be smarter about hs-boot and lhs-boot files
by GHC 14 Feb '18

14 Feb '18

#14809: Invocation of ghc with --make flag should be smarter about hs-boot and lhs- boot files -------------------------------------+------------------------------------- Reporter: mrkkrp | 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: -------------------------------------+------------------------------------- Currently, `--make` in handy for compiling programs with boot files using only one `ghc` invocation. But it behaves strange. If I pass `A.hs`, `B.hs`, and `A.hs-boot` (where `B.hs` imports module `A` with that `{-# SOURCE -#}` thing), I get an error message complaining about module `A` defined twice. Surely GHC should be able to figure out that if the second file has the extension `hs-boot`, it's a boot file and should be used as such. After all, GHC is perfectly capable of finding boot files if it's given import directories to search in (with `-i`). We can't however easily use that because it so happens that if we tell ghc about such directories, they can contain files that should not be visible. I even tried a workaround: copy all boot files to a separate location and then point to that location with `-i`. To my surprise in that case ghc does not pick up those boot files. (And with more complex nesting of modules I expect more problems with this approach.) So it would be great if we could just feed all the relevant files into ghc and it would be smart enough not to complain about modules defined twice if one of the modules is in a file with `hs-boot` or `lhs-boot` extension, but use it as a boot file for corresponding module. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14809> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0