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.