[GHC] #12070: SMP primitives broken on power(pc)

[GHC]

#12070: SMP primitives broken on power(pc)
-------------------------------------+-------------------------------------
           Reporter:  hvr            |             Owner:  trommler
               Type:  bug            |            Status:  new
           Priority:  highest        |         Milestone:  8.0.1
          Component:  Runtime        |           Version:  8.0.1-rc4
  System                             |
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 I originally noticed this when working on the AIX port (32-bit powerpc),
 and recently saw this also on Linux/powerpc64, which lead to talking to
 Peter Trommler who already had a suspicion:

 Here's for example the CAS definition (in `<stg/SMP.h>`):

 {{{#!c
 StgWord
 cas(StgVolatilePtr p, StgWord o, StgWord n)
 {
     StgWord result;
     __asm__ __volatile__ (
         "1:     ldarx     %0, 0, %3\n"
         "       cmpd      %0, %1\n"
         "       bne       2f\n"
         "       stdcx.    %2, 0, %3\n"
         "       bne-      1b\n"
         "2:"
         :"=&r" (result)
         :"r" (o), "r" (n), "r" (p)
         :"cc", "memory"
     );
     return result;
 }}}

 The important detail is the lack any barrier instructions, such as `isync`
 at the end. This results in infrequent heap-corruptions which in turn
 result in all sorts of infrequent and hard to track down runtime-crashes
 (including in `ghc -j`).

 Peter has already a patch in the works which simply replaces the atomic
 powerpc primitives with `__sync_*` intrinsics which turn out to be more
 portable than inline-asm. I've been testing the patch already and it seems
 to have made all issues I experienced so far disappear, as well as fixing
 the `concprog01` test which was also failing infrequently.

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