From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21298 invoked by alias); 10 Jan 2012 19:14:18 -0000 Received: (qmail 21288 invoked by uid 22791); 10 Jan 2012 19:14:16 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Jan 2012 19:14:03 +0000 From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/51766] [4.7 regression] sync_fetch_and_xxx atomicity Date: Tue, 10 Jan 2012 19:14:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-01/txt/msg01110.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766 Andrew Macleod changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amacleod at redhat dot com --- Comment #13 from Andrew Macleod 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.