[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