[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 trommler):

 One other thought: The code generator offers a write barrier primitive
 (which is a store-store barrier I think) but no read barrier (load-load
 barrier).
 The latter is not required on x86 and SPARC TSO but on PowerPC (and
 perhaps on ARM as well) read barriers are required in certain
 circumstances.

 I started to look into this a while ago but I did not find places where
 PowerPC would be allowed to reorder reads and would thus read stale
 data despite the presence of a write barrier on the writing processor.

 If I remember correctly: In cases where we have a data dependency
 (following a pointer)
 or control dependency (conditional branch) no barrier instruction is
 required on PowerPC. All cases I looked at in the code generator
 so far were of one these dependencies. But my search was neither
 systematic nor exhaustive. Unfortunately, I did not take any notes at the
 time.

 Note: `includes/stg/SMP.h` offers a load-load barrier for code (C and Cmm)
 in the RTS.

 I think it is surprising that ARM 6/7 do not seem to have those issues.
 The memory consistency model would be the same, wouldn't it?

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