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.
