#15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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 bgamari): I really wish `MO_WriteBarrier` had some documentation. I added a comment documenting my understanding in Phab:D5029. It would be good to have more eyes on it.
If I'm reading this bit correctly, as a frontend, we shouldn't have to emit any fences to ensure the semantics of seq_cst. If the target machine's memory model would require a fence to encode a load atomic ... seq_cst then it's on llc to emit it, not GHC, right? This seems to be contradicted by this equation in genCall:
I agree; I would have thought that we need to pass the barrier to LLVM regardless of whether the hardware requires it; afterall, there is otherwise nothing to stop LLVM's optimiser from violating the barrier. That being said, this clearly isn't the cause of the AArch64 issues.
I think I'll try the sledgehammer approach of sticking fences before each atomic read and after each atomic write; if the behavior improves at least that's some evidence this is where the issue lies.
Sounds like a good first step. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15449#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler