[GHC] #10176: Invalid core generated with GHC 7.10 RC3
GHC
ghc-devs at haskell.org
Sat Mar 21 19:41:27 UTC 2015
#10176: Invalid core generated with GHC 7.10 RC3
-------------------------------------+-------------------------------------
Reporter: NeilMitchell | Owner:
Type: bug | Status: new
Priority: high | Milestone: 7.10.1
Component: Compiler | Version: 7.10.1-rc3
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: None/Unknown | Unknown/Multiple
Blocked By: | Test Case:
Related Tickets: | Blocking:
| Differential Revisions:
-------------------------------------+-------------------------------------
Comment (by nomeata):
I think I found it. The problem is a bad interaction between Call Arity
and simplification based on the strictness result.
Consider this code:
{{{
e x = error "foo" x
... case e () () of {} ...
}}}
The strictness signature for `e` will be `<L,U>b`. Note the `b`: This
means: „If you give me one argument, then I’m going to be ⊥, which is
true.
The Call Arity for `e` is `2`, which is true: `e` is always called with
two arguments.
So the simplifier phase following Call Arity will replace with
{{{
e x y = error "foo" x y
}}}
At the same time, the simplifier will replace `e () ()` with `e ()`. After
all, both are known to be bottom. The result (after inlining) is the bogus
{{{
... case (\y -> error "foo" x y) of {} ...
}}}
that we see.
The simplifier looks at the `b` flag of the strictness analyzer in
`mkArgInfo`, replacing `isBotRes result_info` with `False` makes the
problem go away, but that is probably not the solution.
Zapping strictness analysis when Call Arity finds something is probably
also a bad idea.
Maybe the best solution is to limit the number found by call arity to the
number of arguments in the strictness signature, if the strictness
signature ends in a `b`.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10176#comment:15>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list