#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