[GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>)

[GHC]

#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into
<<loop>>)
-------------------------------------+-------------------------------------
        Reporter:  exio4             |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.10.1
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  Incorrect result  |  Unknown/Multiple
  at runtime                         |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by simonpj):

 That's extremely helpful, thank you Reid.

 I'm guessing that the culprit, somehow, is this code in `CoreToStg`:
 {{{
     upd_flag | isSingleUsed (idDemandInfo bndr)  = SingleEntry
              | otherwise                         = Updatable
 }}}
 This arranges not to black-hole a thunk that is used at most once.  Can
 you try with `-fkill-one-shot`?  That switches off this optimisation, and
 I bet it'll make the program work.

 Assuming that does fix it, the next question is: is it just the
 `CoreToStg` `upd_flag`?  (`-fkill-one-shot` affects more things than just
 that one spot.)  The next thing I'd do would be just to comment out the
 `SingleEntry` case above, rebuild the compiler, and check that the bug is
 gone.  I'm 95% sure that it'll will, but worth checking.

 Next.  If some thunk is being marked `SingleEntry`, and that that is
 causing the bug:
  * Which thunk is it?
  * Is it really single-entry?  (I.e. is the analysis right or not)

 If you `-ddump-stg` and look for thunks marked `\s`, those are the single-
 entry ones.  There probably aren't very many.  If it's very few, we could
 look at the "is the analysis right?" question. If it's many, we'll need to
 find a way to narrow it down somehow.

 Simon

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10414#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler