#1171: GHC generates incorrect code with -O for Haskell 98 program
----------------------+-----------------------------------------------------
Reporter: neil | Owner:
Type: bug | Status: reopened
Priority: low | Milestone: _|_
Component: Compiler | Version: 6.6
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: cg059 | Architecture: Multiple
Os: Multiple |
----------------------+-----------------------------------------------------
Changes (by simonpj):
* resolution: invalid =>
* milestone: 6.6.1 => _|_
* priority: normal => low
* severity: major => normal
* status: closed => reopened
Comment:
Indeed our paper
[http://research.microsoft.com/~simonpj/Papers/imprecise-exn.htm]
is good background reading for this.
Consider
{{{
f :: Bool -> Int -> Int
f True x = error "urk"
f False x = x
}}}
We'd probably agree that f is strict. And hence we can use call-by-value.
But look at the consequences:
{{{
g x = f x (error "flop")
}}}
Since f is strict, we'll use call-by-value, and hence g will (always)
craxh with "error: flop". But is that right? After all, if we simply
inline f we get
{{{
g x = case x of
True -> error "urk"
False -> error "flop"
}}}
which is very similar to your program. (In your case GHC has made the
reverse transformation, lifting one of your case branches out as a shared
expression.)
So by doing strictness analysis, GHC is increasing the set of exceptions
(see the paper) in the denotation of the program. That's a bit confusing,
I grant. It's easily stopped, too, by stopping GHC treating error like
bottom; but that would make many functions less strict. It'd be
interesting to measure the performance impact of this.
So I'm re-opening the bug because I think it's a legitimate and
interesting question what the "right" behaviour should be. I'd like to
add a flag to GHC to give the more conservative behaviour. It's the
first time this has happened; interesting!
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1171>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
