[Bug middle-end/51766] [4.7 regression] sync_fetch_and_xxx atomicity

[amacleod at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com

--- Comment #13 from Andrew Macleod <amacleod at redhat dot com> 2012-01-10 19:13:44 UTC ---
I don't think it matters what the original rationale was for implementing
__sync. They are documented as being seq-cst.

I would argue that power implementing them not as seq-cst is not truly
compliant.  It shouldn't be too difficult to write a test case using __sync
which expects seq-cst as documented that would pass on all targets except
power.

It may be that power-specific programmers have been taking advantage of this,
but doesn't it has to have the potential to break generic code?... (lucky TM
only needed relaxed atomics!)

That said... it would be possible to simply have an optional macro with a
default definition of 
  #define __SYNC_LEGACY_MODE   MEMMODEL_SEQ_CST
and if a port like power wants something different, it can define
  #define __SYNC_LEGACY_MODE   MEMMODEL_ACQ_REL

then use that value instead of MEMMODEL_SEQ_CST for legacy __sync routines.

Would that satisfy all your requirements?  shouldn't really need any other
changes then.  Although as Jakub says, it should then be clearly documented.