#15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: tmobile Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tmobile): Sorry for my slowness on this; I've been busy with other things at work and we have yet to actually trigger this bug with out code on aarch64 for some reason, so I haven't had time to take a look. Now that I understand a bit better I agree that `stg_BLACKHOLE` is unlikely to blame. Ben, I'll give your patch a go, but it seems strange that we update the indirectee straight away in the macro; why not do something like: {{{ #define updateWithIndirection(p1, p2, and_then) \ W_ bd; \ \ OVERWRITING_CLOSURE(p1); \ SET_INFO(p1, stg_BLACKHOLE_info); \ LDV_RECORD_CREATE(p1); \ prim_write_barrier; \ StgInd_indirectee(p1) = p2; \ bd = Bdescr(p1); \ if (bdescr_gen_no(bd) != 0 :: bits16) { \ recordMutableCap(p1, TO_W_(bdescr_gen_no(bd))); \ TICK_UPD_OLD_IND(); \ and_then; \ } else { \ TICK_UPD_NEW_IND(); \ and_then; \ } }}} Is it just that we don't care when other HECs see the side effects of SET_INFO? It seems to me that doing SET_INFO after the write barrier could cause you to race too. And as far as SPARC goes, IIRC SPARC machines are actually in TSO mode by default, and programs must explicitly switch to RMO or PSO mode. SPARC TSO provides essentially the same guarantees as X86. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15449#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler