Bad news: apparent bug in casMutVar going back to 7.2

Ryan Newton rrnewton at
Sat Feb 1 05:33:59 UTC 2014

I commented on the commit here:

The problem is that our "cas" routine in SMP.h is similar to the C compiler
intrinsic __sync_val_compare_and_swap, in that it returns the old value.
 But it seems we cannot use a comparison against that old value to
determine whether or not the CAS succeeded.  (I believe the CAS may fail
due to contention, but the old value may happen to look like our old value.)

Unfortunately, this didn't occur to me until it started causing bugs [1]
[2].  Fixing casMutVar# fixes these bugs.  However, the way I'm currently
fixing CAS in the "atomic-primops" package is by using

What is the best fix for GHC itself?   Would it be ok for GHC to include a
C compiler intrinsic like __sync_val_compare_and_swap?  Otherwise we need
another big ifdbef'd function like "cas" in SMP.h that has the
architecture-specific inline asm across all architectures.  I can write the
x86 one, but I'm not eager to try the others.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list