[GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1

[GHC]

#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