#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 MikolajKonarski): * cc: MikolajKonarski (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12620#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): That all looks possible. Since `nofloat` does several things, it may not be long before people start asking for variants that do some combination of its properties. But I guess we can jump that bridge if we come to it. It would be useful to give some compelling use-cases. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12620#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by edsko): * related: => #9520, #8457 Comment: Right, so a lot of the thinking that led to this ticket came from trying to understand memory leaks in conduit code. See my recent blog post http://www.well-typed.com/blog/2016/09/sharing-conduit/ where these issues are described in great detail; this should also serve, I hope, as one "compelling use case". That said, I like the idea of a "noupdate" much better than a "nofloat". It would seem to me that its semantics would be easier to specify; and if it means I don't have to think so hard about what exactly the optimizer is doing to my code in order to understand why I do or do not have a memory leak, that would very welcome. I really like @duncan 's suggestion of having a type annotation on a type; though we might also want some adhoc way of saying "make ''this'' thunk not-updateable". An easyish experiment perhaps might be to declare a magic datatype {{{#!hs data DontUpdate a = DontUpdate a }}} with the property that any code that looks at the thunk in the payload of `DontUpdate` doesn't cause that thunk to be updated. Then in @duncan 's example we could define {{{#!hs data Pipe i o r = Yield o (DontUpdate (Pipe i o r)) }}} That said, I'm not sure exactly what DontUpdate should do for the lambda; but this is a question about @duncan's proposal too. I ''think'' what we want to happen is that the thunks in the function closure never get updated (this, in a nutshell, is what is causing memory leaks in conduit code; see the blog post); but that's already more magical than just saying "don't update this thunk". -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12620#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duncan): Right, this is an initial idea and hasn't been fleshed out. Thanks for the probing example :-) So the intention is that it's a purely local thing. So in that example, the answer is no, we do not expect a caller far away to have to know anything. The idea is that evaluating "via" the noupdate field should not perform thunk updates, but I appreciate that may not match how thunk construction and update works. So how about something like this... Suppose the primitive is not on fields, but on let. This is by analogy with strict `let !_ =` versus strict constructor fields. The primitive with strictness is at use sites and a convenience for systematic use we can push it to constructor fields, which is defined in terms of constructor wrappers. So suppose the primitive is `let {-# NOUPDATE #-} x = ...`, and so then the `Yield` constructor above could perhaps be defined with a wrapper like {{{#!hs data Pipe i o r = Yield o {-# NOUPDATE #-} (Pipe i o r) yield o x = let {-# NOUPDATE #-} x' = x in Yield o x' }}} So in your `f x` example above then this would do very little (and indeed we'd want it to do precisely nothing different to the usual, by shorting out the extra let indirection). But if things are defined with `Yield (expr)` or locally ghc decides to float/push things in, then the expression would end up in the `let {-# NOUPDATE #-} x' = ...` and so there would be an effect. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12620#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Replying to [comment:7 simonpj]:

I think that "noupdate" would require some careful thought. What if I say {{{ f x = if ... then Yield blah x else ... }}} Then the "noupdate" second field of `Yield` is just the parameter to `f`. Does the caller have to know not to build an updatable thunk.

I guess we would instruct the demand analysis to believe that `Yield` has strictness signature `` and thus this once-used information will be propagated, at least to the extent possible. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12620#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tomjaguarpaw): Edsko, it seems to me that the problem that you mention here is quite easy to avoid. {{{#!hs main :: IO () main = retry $ return () >>= \_ -> ni_mapM_ print [1..1000000] }}} is sufficient, unless I am very much mistaken. With such a construction the list is allocated afresh for each invocation of the `IO` action. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12620#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by WrenThornton): It looks like that fix only works for the default optimization level. Passing -O2 reintroduces the problem with `retry` -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12620#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tomjaguarpaw):

Edsko, I'm a bit puzzled. For the case of conduits, isn't it enough to hide things behind lambdas in the definition of the Pipe type?

That is, "enough module full laziness". -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12620#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tomjaguarpaw): This is why my suggestion is ''exactly'' to tweak the conditions when full laziness fires! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12620#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jpbernardy): As it turns out, we currently have a proposal on the table which is capable of expressing where sharing should not occur, in a principled way, by using types. This page sums up how it may play out in Edsko's example. https://ghc.haskell.org/trac/ghc/wiki/LinearTypes/Examples#Controllingsharin... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12620#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

I'm beginning to get glimmers of understanding about this no-update

{{{ t1 = [1..n] vs t2 = \_ -> [1..n] vs t3 = let x = [1..n] in \_ -> x }}} Note that

* If we use `t1` in a shared context like `sum t1 / length t1`, we'll end up materialising the whole list. * For `t2`, we'd get `sum (t2 ()) / length (t2 ())`, and now the list is computed twice rather than duplicated. Note that `t1` and `t2` have different types of course. * Then `t3` is the result of applying the full laziness transformation to `t2`, and its space behaviour is back to that of `t1`.

Reflections:

* I think that this "noupdate" pragma is intended to achieve an effect

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): The more I think about this, the less convinced I am that a `nofloat` or even a local `noupdate` annotation really helps. The problem is: where do we put the annotation? The whole point of having such an annotation, as opposed to just disabling full laziness in the whole module, is to have more fine grained control over where full laziness applies and where it doesn't. This was easy in the example that this ticket started with {{{#!hs enum xs = zip (nofloat [1..]) xs }}} but it's far less obvious in larger examples. For example, consider the definition of a conduit that implements the HTTP protocol (Michael Snoyman's http-conduit package), or a conduit that does constant space type inference for large JSON documents (an example from the code base I am working on). Now how do we know what in these definitions to mark as `nofloat`? If we get it wrong, then full laziness might float something else out that we weren't expecting, and we might once again end up with a difficult to debug space leak. The only really workable solution would be to mark the whole body as `nofloat`, but now we've lost the advantage of fine granularity. I'm guessing @tomjaguarpaw will say at this point "see! the problem is full laziness itself" and to be honest, I'm starting to get more and more convinced by that point of view. However, I still believe that there is an alternative by means of the NOUPDATE annotation. But, having thought about it more, I don't think annotating the ''constructors'' is the right approach. @simonpj asks for a minimal example, so let's consider this one: {{{#!hs module Main (main) where import System.IO.Error data Sink = Await (Maybe Char -> Sink) | Done Int countFrom :: Int -> Sink countFrom n = Await $ \mi -> case mi of Nothing -> Done n Just _ -> countFrom $! n + 1 feedFrom :: Int -> Sink -> IO () feedFrom _ (Done n) = print n feedFrom 0 (Await f) = feedFrom 0 (f $ Nothing) feedFrom n (Await f) = feedFrom (n - 1) (f $ Just 'A') retry :: IO a -> IO a retry io = catchIOError io (\_ -> retry io) main :: IO () main = retry $ feedFrom 1000000 (countFrom 0) }}} A `Sink` (a special kind of "conduit") is some kind of automaton that accepts (`Await`s) a bunch of inputs (in this case `Char`s) and at some point terminates (`Done`). Let's recap from the blog post why this has a space leak: 1. `feedFrom 1000000 (countFrom 0)` is a PAP (waiting for its `State# RealWorld` argument) 2. When `retry` executes the action, it maintains a reference to that PAP from the exception handler. 3. In the environment of the PAP is a thunk corresponding to `countFrom 0`. 4. Finally, and crucially, full laziness is turning the definition of `countFrom` to something more akin to {{{#!hs -- Full laziness turns countFrom into: countFrom :: Int -> Sink countFrom n = let k = countFrom $! n + 1 in Await $ \mi -> case mi of Nothing -> Done n Just _ -> k }}} (The example with the original definition of `countFrom` has a space leak when compiled with `-O` but no space leak with `-O -fno-full-laziness`; if we use this version of `countFrom`, we have a space leak with or without full laziness enabled.) (1)-(4) together means that there is a reference from the PAP's environment to the `countFrom 0` thunk, and as `feedFrom` evaluates that thunk we build up a long chain {{{ Await ---payload---> FUN ---environment---> Await ---payload---> ... }}} where every `Await` constructor has a function as its payload, and that function has a reference to the next `Await` constructor in its environment (closure) (section "Full laziness versus sinks" of http://www .well-typed.com/blog/2016/09/sharing-conduit/ has some pictures.). So what's the solution here? Perhaps one might argue that full laziness is the culprit here; it should not have floated out that continuation in `countFrom`. Like I said, I'm starting to have a lot of sympathy for that point of view; I will soon need to publish an erratum to my blog post because I was once again underestimating full laziness. BUT. We can ask a different question: do we really want to be thinking so hard about when and where things get allocated precisely? What if the user ''themselves'' wrote that alternative version of `countFrom` -- after all, it seems like an innocuous change. Should we really have to think so low- level when writing Haskell code? I would like to be able to answer "no" to that question. Here's the thing: conduits (and other structures like it) are data structures designed to drive computation; we _never_ expect them to be shared and built up in memory. (When we were discussing these matters at Well-Typed a comparison was drawn to data versus codata.) I think it would be great if we could express this, and `NOUPDATE`, I think, might allow us to do that. However, I now think annotating the constructors is not the right approach. In addition to Simon's probing questions, above, let's consider the example `countFrom`. What is the thunk that we don't want to be updateable? Well, `countFrom 0` really; and, if pressed for another one, the `Sink` in the environment of the continuation in countFrom (`countFrom $! n + 1`). ''Neither of those is the argument to a constructor.''. I think that instead we should annotate the ''type'': {{{#!hs {-# NOUPDATE Sink #-} data Sink = Await (Maybe Char -> Sink) | Done Int }}} Now questions such as "who created this thing? do we need spooky action at a distance?" are no longer relevant. It's simple and type directed. Any thunk of type `Sink` never gets updated. Some other minor bits and bobs: Replying to [comment:19 simonpj]: thing. Consider like `t2`, but more conveniently, without changing types. Correct? Exactly. If we had a list type that was marked as `NOUPDATE`, then `sum t1 / length t1` would not have a space leak (though the list would be evaluated twice).

* I think (but am not sure) that you intend to use this only for one- shot thunks, where (unlike the sum/count example) the thunk is evaluated only once. In which case it would often be discarded after being evaluated, in which case where does the leak come from. A small, concrete example would be jolly useful.

No, I don't think that's necessarily the case. Marking something as `NOUPDATE` would imply that you're okay with it being evaluated more than once; indeed, that's what you want. In the minimal example I've been discussing in this comment, we ''want'' that conduit (sink) to be re- evaluated should the exception handler be run.

* Notice how important it is that in `t2` the lambda ''syntactically encloses'' the leaky computation. Otherwise you get `t3`.

I think this is another reason to move to a type directed approach instead. Syntactic enclosure is too brittle and too prone to be affected by the optimizer. Replying to [comment:20 jpbernardy]:

As it turns out, we currently have a proposal on the table which is capable of expressing where sharing should not occur, in a principled way, by using types.

This page sums up how it may play out in Edsko's example.

https://ghc.haskell.org/trac/ghc/wiki/LinearTypes/Examples#Controllingsharin...

Hmmm, I had not realized the connection to linearity, and I wasn't aware of this work. Must take a closer look (my PhD is on uniqueness typing :). I'm not sure however that linearity is what we want here. Do we want to reject a definition such as {{{#!hs someConduit = do x <- await case x of True -> do foo ; someConduit False -> do foo ; someConduit }}} If conduits can never be shared, this would be type incorrect. This would seem too restrictive. `NOUPDATE` in a way is kind of opposite to linearity: it's fine to share, just make sure that every time we access this value we recompute it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12620#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): Related work: Joachim Breitner's (unpublished) paper "dup – Explicit un- sharing in Haskell" (https://arxiv.org/pdf/1207.2017v1.pdf). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12620#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): Replying to [comment:25 simonpj]:

...

Any thunk of type `Sink` never gets updated. Notice the "`-o`", meaning a "one-shot function". The idea is that one- shot functions are called at most once. (Maybe exactly once, but I think at-most once is better.)

So in your `countFrom` example, the continuation `k` would not be floated outside the lambda; and if it was written outside it'd be floated inside the lambda.

GHC already has the notion of a one-shot lambda; it's just not dignified as part of the type system.

Would that serve? I think that you do intend that the argujment of `Await` is called at most once, don't you?

Typically, yes, but not necessarily. After all, in the minimal example above, ''if'' the exception handler gets executed then the whole process starts over. Ideally it would start over with a newly constructed conduit, but if we cannot prevent sharing, it would start over with the same conduit. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12620#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): But perhaps I misunderstood: yes, marking the ''function type'' as "oneshot" `Maybe Char -o Sink` would also do the trick. Although I'm not a fan of calling this "oneshot", or indeed the `-o` notation (borrowed from linearity). The whole point is that these functions _might_ be executed more than once; after all, if we were guaranteed that that wouldn't happen, we wouldn't be hanging on to them and there would be no memory leak. But marking that function as "noupdate" or whatever would seem to make sense; of course, now we can ask the same question as you asked above: what about {{{#!hs foo :: Maybe Char -> Sink {-# NOUPDATE foo #-} foo = if <expensive> then f1 else f2 }}} but I guess this is far less likely to be a problem in practice; how often do we write something like {{{#!hs await >>= if <expensive> then f1 else f2 }}} I think almost never; this is far more likely {{{#!hs await >>= \mi -> if <expensive> then c1 else c2 }}} and that would be just fine. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12620#comment:28 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by michaelt): If I add a monad instance, then I can give the customary definition `await = Await Done`. If I delay inlining, then the standard use of `await` works fine in the presence of this rule {{{ {-# RULES "await hack" forall f . await >>= f = Await (oneShot f) #-} }}} In a library for your `Sink` type, this would I think get rid of the problem. See the attached https://ghc.haskell.org/trac/ghc/attachment/ticket/12620/awaithack.hs -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12620#comment:29 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12620#comment:31 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: CSE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harendra): * cc: harendra (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12620#comment:33 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler