Re: [GHC] #10176: Invalid core generated with GHC 7.10 RC3

#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 `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