October 2017 - ghc-tickets

[GHC] #9539: TQueue can lead to thread starvation
by GHC 12 Jun '18

12 Jun '18

#9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.2 Keywords: stm | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- For background, please see [http://stackoverflow.com/questions/25536604 /huge-memory-consumption-for-simple-multithreaded- haskell/25560047#25560047 this SO question] When using TQueue, a sufficiently fast/persistent writer can result in the reader never getting scheduled, causing the queue to continually grow and lost concurrency. I believe the issue is caused by the definition of readTQueue: {{{ readTQueue :: TQueue a -> STM a readTQueue (TQueue read write) = do xs <- readTVar read case xs of (x:xs') -> do writeTVar read xs' return x [] -> do ys <- readTVar write case ys of [] -> retry _ -> case reverse ys of [] -> error "readTQueue" (z:zs) -> do writeTVar write [] writeTVar read zs return z }}} Note that the last `case` needs to traverse the write-end of the queue within the STM transaction. If the list is sufficiently large, a writer can commit a new transaction much more quickly, invalidating the read transaction. If threads continue to write to the queue, the reader will never get an opportunity to commit (and the list will grow, exacerbating the problem). This alternative definition seems to fix the problem, but I don't know if there are other drawbacks to using it. {{{ readTQueue' :: TQueue a -> STM a readTQueue' (TQueue read write) = do xs <- readTVar read case xs of (x:xs') -> do writeTVar read xs' return x [] -> do ys <- readTVar write case ys of [] -> retry _ -> do writeTVar write [] let (z:zs) = reverse ys writeTVar read zs return z }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9539> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #13154: Standalone-derived anyclass instances aren't as permissive as empty instances
by GHC 11 Jun '18

11 Jun '18

#13154: Standalone-derived anyclass instances aren't as permissive as empty instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | 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: -------------------------------------+------------------------------------- Note that these are accepted: {{{#!hs class Foo (a :: TYPE ('TupleRep '[])) instance Foo (a :: TYPE ('TupleRep '[])) instance Foo (##) }}} But if you try to write these same instances using `DeriveAnyClass` and `StandaloneDeriving`, they'll be rejected for no good reason: {{{#!hs deriving instance Foo (a :: TYPE ('TupleRep '[])) {- • Can't make a derived instance of ‘Foo a’: The last argument of the instance must be a data or newtype application -} deriving instance Foo (##) {- • Can't make a derived instance of ‘Foo (# #)’: The last argument of the instance cannot be an unboxed tuple -} }}} The latter error is a vestige of #12512, and should be easy enough to rectify. The former error is a bit tricker to fix, since much of the code in `TcDeriv`/`TcDerivInfer` assumes that the type to which the class is applied to in the instead head is a datatype or newtype `TyCon`. It's apparent that this doesn't hold true in the presence of `DeriveAnyClass`, however, so that code should be refactored to reflect this. For practical reasons, however, it might be best to wait until after #12144 is fixed to tackle this one, since that splits out some logic in `TcDerivInfer` for `DeriveAnyClass` so as to make it no longer rely on the aforementioned `TyCon` invariant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13154> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #11798: Recompiling with -fhpc flag added does nothing
by GHC 10 Jun '18

10 Jun '18

#11798: Recompiling with -fhpc flag added does nothing -------------------------------------+------------------------------------- Reporter: drathier | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- When you recompile without modifiying any source code, nothing happens, as expected. The file is already compiled, after all. If you then add the -fhpc flag, it still doesn't recompile, even though it now should generate .tix files. These files are now unexpectedly missing, until the source files are modified or the .o and .hi files are deleted, and the code is recompiled again with the -fhpc flag. reproduce: 1. compile program 2. compile program with -fhpc note: missing .tix file 3. delete .hi and .o files 4. compile program with -fhpc 5. success; .tix file is generated -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11798> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications
by GHC 08 Jun '18

08 Jun '18

#11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Originally reported [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010915.html here]. When applying types via `-XTypeApplications`, the type/kind that gets instantiated seems to be different depending on whether you're using functions, datatypes, or typeclasses. Here's an example contrasting functions and datatypes: {{{ $ /opt/ghc/head/bin/ghci GHCi, version 8.1.20160106: http://www.haskell.org/ghc/ :? for help λ> :set -fprint-explicit-kinds -XTypeApplications -XTypeInType λ> data Prox a = Prox λ> prox :: Prox a; prox = Prox λ> :t prox prox :: forall k (a :: k). Prox k a λ> :t prox @Int prox @Int :: Prox * Int λ> :t Prox Prox :: forall k (a :: k). Prox k a λ> :t Prox @Int Prox @Int :: Prox Int a }}} This is the core of the problem: with a function, `Int` seems to be applied to type variable `a`, whereas with data types, `Int` appears to be applied to the kind variable `k`. This confuses me, since `k` wasn't specified anywhere in the definition of `Prox`. Andres Löh also [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010916.html observed] a similar discrepancy between functions and typeclasses: {{{ λ> :set -XScopedTypeVariables λ> class C a where c :: () λ> d :: forall a. C a => (); d = c @_ @a λ> :t d d :: forall k (a :: k). C k a => () λ> :t d @Int d @Int :: C * Int => () λ> :t c c :: forall k (a :: k). C k a => () λ> :t c @Int c @Int :: C Int a => () λ> :t c @_ @Int c @_ @Int :: C * Int => () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11376> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 37

[GHC] #12023: Problems getting information and kind from GHC.Prim ~#, ~R#, ...
by GHC 07 Jun '18

07 Jun '18

#12023: Problems getting information and kind from GHC.Prim ~#, ~R#, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 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: -------------------------------------+------------------------------------- {{{ >>> import GHC.Prim >>> :bro GHC.Prim [...] type role (~#) nominal nominal data (~#) (t3 :: a) (t4 :: b) type role ~P# phantom phantom data ~P# (t3 :: a) (t4 :: b) type role (~R#) representational representational data (~R#) (t3 :: a) (t4 :: b) }}} getting the kind of `~`, `~#`, `~~` works fine: {{{ >>> import GHC.Prim >>> import GHC.Types >>> :kind (~) (~) :: k -> k -> Constraint >>> :kind (~#) (~#) :: a -> b -> TYPE 'VoidRep >>> :kind (~~) (~~) :: j -> k -> Constraint }}} but `#` gets incorrectly treated as an operator in `~R#` and `~P#`: {{{ >>> :kind (~R#) <interactive>:1:3: error: Illegal operator ‘#’ in type ‘~R #’ Use TypeOperators to allow operators in types <interactive>:1:3: error: Operator applied to too few arguments: ~R # <interactive>:1:4: error: Not in scope: type constructor or class ‘R’ }}} Furthermore while running `:info` on `~~` and `~#` works fine {{{ >>> :info (~~) class a ~# b => (~~) (a :: j) (b :: k) -- Defined in ‘GHC.Types’ >>> :info (~#) type role (~#) nominal nominal data (~#) (t3 :: a) (t4 :: b) -- Defined in ‘GHC.Prim’ }}} the others don't parse {{{ >>> :info (~) <interactive>:1:2: error: parse error on input ‘~’ >>> :info (~R#) <interactive>:1:2: error: parse error on input ‘~’ >>> :info (~P#) <interactive>:1:2: error: parse error on input ‘~’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12023> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends
by GHC 07 Jun '18

07 Jun '18

#14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: ghc-pkg | 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: -------------------------------------+------------------------------------- In GHC 8.2, we introduced `abi-depends` to solve #12485. Following the same pattern as all ghc-pkg fields, this field is to be fllled by whoever is performing the registration. I now suspect designing it this way was a mistake. In https://github.com/haskell/cabal/issues/4728 we have a bug where Cabal is writing nonsense data for `abi-depends`, `ghc-pkg` isn't noticing it, and GHC is rejecting the package (with a "shadow" warning) when it gets to the end. The problem is the Cabal aggressively caches the contents of the package database (ostensibly because it is expensive to query `ghc-pkg`); this means that it is easy to get into a situation where its understanding of the ABIs of its dependencies is out-of-date (because it is not re- reading the database in order to get newer information). The insult to the injury is, in most cases, ghc-pkg already knows what the ABIs are supposed to be: they're whatever the ABIs of the packages pointed at by 'depends' already in the database are. So ghc-pkg could have computed the abi dependency itself, and prevented this stale data situation from ever happening. This sounds quite attractive to me. What do people think? Here is one possible proposal (but it is just one in the space): * `ghc-pkg` will be modified to ignore the `abi-depends` field (perhaps with a warning), to prevent itself from being poisoned by buggy versions of Cabal which are giving bad ABI information * Instead, `ghc-pkg` generates the `abi-depends` field by looking up dependency IDs from the database. If an ID is not found, it omits the dep from `abi-depends` (this is equivalent to suspending ABI checking in GHC, so this won't break anything; it will just make ABI checking less robust) * Possibly, introduce a new "virtual" field, which can be used to override `ghc-pkg` default -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14381> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #13438: ghci :browse does not work with DuplicateRecordFields
by GHC 07 Jun '18

07 Jun '18

#13438: ghci :browse does not work with DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: rik | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple duplicaterecordfields ghci | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using `:browse` on module which has enabled DuplicateRecordFields and datatypes are exported, does not return the field accessor functions. So for example: {{{#!hs data Login = Login { code :: Text , password :: Text } )}}} `browse` for module does not return `code` and `password` accessor functions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13438> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13471: segmentation fault by compiling GHC
by GHC 06 Jun '18

06 Jun '18

#13471: segmentation fault by compiling GHC -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi,\\ I tried to compile GHC on my computer.\\ by compiling GHC under Linux I got this error message.\\ {{{ compiler/ghc.mk:588: recipe for target 'compiler/stage2/build/DynFlags.o' failed make[1]: *** [compiler/stage2/build/DynFlags.o] segmentation fault Makefile:122: recipe for target 'install' failed make: *** [install] Error 2 }}} on my computer Linux runs on VirtualBox.\\ the problem is probably with my hardware but as I know nothing I tell you this issue.\\ {{{ ~/ghc/inplace/bin$ /ghc-stage1 --version The Glorious Glasgow Haskell Compilation System, version 8.3.20170322 }}} Hope this help\\ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13471> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12075: Fails to build on powerpcspe because of inline assembly
by GHC 05 Jun '18

05 Jun '18

#12075: Fails to build on powerpcspe because of inline assembly --------------------------------+---------------------------------------- Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: powerpc | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Hello! I'm currently bootstrapping GHC on powerpcspe (e500v2) which is a PowerPC architecture without an FPU but with signal processing extensions (hence SPE). When building GHC on this architecture, it detects the host architecture as powerpc-linux-gnuspe or short "powerpc" which works most of the time. However, GHC contains some inline assembly in rts/StgCRunAsm.s which uses FPU instructions not available on e500v2 CPUs resulting in assembler error, here with GHC 7.10.3: {{{ "inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing- declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist- derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc- Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc- DUSE_LIBFFI_FOR_ADJUSTORS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/autogen -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-w -static -H32m -O -lffi -optl-pthread -lffi -optl-pthread -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/StgCRun.c -o rts/dist/build/StgCRun.o /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) /tmp/ghcf20d_0/ghc_1.s: Assembler messages: /tmp/ghcf20d_0/ghc_1.s:24:0: Error: unrecognized opcode: `stfd' (...) /tmp/ghcf20d_0/ghc_1.s:67:0: Error: unrecognized opcode: `lfd' /tmp/ghcf20d_0/ghc_1.s:68:0: Error: unrecognized opcode: `lfd' /tmp/ghcf20d_0/ghc_1.s:69:0: Error: unrecognized opcode: `lfd' rts/ghc.mk:236: recipe for target 'rts/dist/build/StgCRun.o' failed make[3]: *** [rts/dist/build/StgCRun.o] Error 1 Makefile:71: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/usr/src/ghc-7.10.3' dh_auto_build: make -j1 returned exit code 2 debian/rules:109: recipe for target 'override_dh_auto_build' failed make[1]: *** [override_dh_auto_build] Error 2 make[1]: Leaving directory '/usr/src/ghc-7.10.3' debian/rules:47: recipe for target 'binary-arch' failed make: *** [binary-arch] Error 2 (sid2-powerpcspe-sbuild)root@atlantis:/usr/src/ghc-7.10.3# }}} This can be verified by commenting out the assembly which will make the above compile command execute without any problems. Trying to continue compiling GHC will still fail with: {{{ "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -lffi -optl-pthread -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) /tmp/ghcca51_0/ghc_3.s: Assembler messages: /tmp/ghcca51_0/ghc_3.s:525:0: Error: unrecognized opcode: `lfs' /tmp/ghcca51_0/ghc_3.s:538:0: Error: unrecognized opcode: `lfd' /tmp/ghcca51_0/ghc_3.s:592:0: Error: unrecognized opcode: `stfs' /tmp/ghcca51_0/ghc_3.s:604:0: Error: unrecognized opcode: `stfd' rts/ghc.mk:236: recipe for target 'rts/dist/build/HeapStackCheck.o' failed make[3]: *** [rts/dist/build/HeapStackCheck.o] Error 1 Makefile:71: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/usr/src/ghc-7.10.3' dh_auto_build: make -j1 returned exit code 2 debian/rules:109: recipe for target 'override_dh_auto_build' failed make[1]: *** [override_dh_auto_build] Error 2 make[1]: Leaving directory '/usr/src/ghc-7.10.3' debian/rules:47: recipe for target 'binary-arch' failed make: *** [binary-arch] Error 2 (sid2-powerpcspe-sbuild)root@atlantis:/usr/src/ghc-7.10.3# }}} So, there is obviously more assembly code that needs to be disabled on powerpcspe. For that, I suggest testing whether the compiler sets __NO_FPRS__which is only set on powerpc hosts without FP registers: {{{ root@atlantis:~# echo | gcc -E -dM -|grep -i FP #define __NO_FPRS__ 1 root@atlantis:~# dpkg --print-architecture powerpcspe root@atlantis:~# uname -m ppc root@atlantis:~# }}} For reference, on a real powerpc host, the output is as follows: {{{ (sid_powerpc-dchroot)glaubitz@partch:~$ echo | gcc -E -dM -|grep -i FP #define __FP_FAST_FMAF 1 #define __FP_FAST_FMA 1 (sid_powerpc-dchroot)glaubitz@partch:~$ dpkg --print-architecture powerpc (sid_powerpc-dchroot)glaubitz@partch:~$ uname -m ppc (sid_powerpc-dchroot)glaubitz@partch:~$ }}} If you need any more input, please let me know. Adrian -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12075> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics
by GHC 04 Jun '18

04 Jun '18

#8516: Add (->) representation and the Invariant class to GHC.Generics ----------------------------------------------+---------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- We currently disallow any use of the parameter in the domain of (->). {{{ newtype F a = F ((a -> Int) -> Int) deriving Generic1 <interactive>:4:38: Can't make a derived instance of `Generic1 (F g)': Constructor `F' must use the last type parameter only as the last argument of a data type, newtype, or (->) In the data declaration for `F' }}} !DeriveFunctor succeeds for this F. I'd like to add this representation type to GHC.Generics and !DeriveGeneric. {{{ newtype (f :->: g) a = FArrow1 (f a -> g a) }}} We could then represent the first example above. We could also derive the more interesting Generic1 (F g). {{{ newtype F g a = F (g a -> Int) deriving Generic1 type instance Rep1 (F g) = Rec1 g :->: Rec0 Int instance Generic1 (F g) where to x = F $ unRec0 . unArrow1 x . Rec1 from (F x) = FArrow1 $ Rec0 . x . unRec1 }}} Admittedly, there's not many generic definitions impeded by not having (:->:). Contra- and in-variant types are uncommon. I'm suggesting this feature without strong motivating examples because I think this would streamline the implementation of -XDeriveGenerics in some ways while also making it more general — assuming that we added the Invariant class to base or ghc-prim. {{{ class Invariant t where invmap :: (a -> b) -> (b -> a) -> t a -> t b invmap_covariant :: Functor t => (a -> b) -> (b -> a) -> t a -> t b invmap_covariant f _ = fmap f instance (Invariant f,Invariant g) => Invariant (FArrow f g) where invmap co contra (FArrow h) = FArrow $ invmap co contra . h . invmap contra co }}} (Of course, Invariant should be a super class of Functor. :/ ) Now we can handle quite involved examples: {{{ newtype F g h a = F (g (h a)) deriving Generic1 instance Invariant g => Generic1 (F g h) where to x = invmap unRec1 Rec1 $ unComp1 x from (F x) = Comp1 $ invmap Rec1 unRec1 }}} All of that said, I'm mostly opening this ticket so I can get feedback on difficulties I might not be anticipating and have a place to reference from the compiler source code comments. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8516> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18