From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6672 invoked by alias); 9 Jan 2012 16:51:16 -0000 Received: (qmail 6658 invoked by uid 22791); 9 Jan 2012 16:51:12 -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; Mon, 09 Jan 2012 16:51:00 +0000 From: "dje at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/51766] [4.7 regression] sync_fetch_and_xxx atomicity Date: Mon, 09 Jan 2012 16:51: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: dje at gcc dot gnu.org 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: 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/msg00887.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766 --- Comment #3 from David Edelsohn 2012-01-09 16:49:10 UTC --- > It says above them "In most cases, these > builtins are considered a full barrier." and only __sync_lock_test_and_set and > __sync_lock_release specify different barrier semantics. The next sentence is: "That is, no memory operand will be moved across the operation, either forward or backward." Note that this refers to memory operands, not memory operations -- memory stores and memory loads referenced in documentation of the other sync builtins. In other words, one could interpret "full memory barrier" as: asm volatile ("" : : : "memory"); that refers to a GCC scheduling barrier. The GCC documentation references Intel processors, which do not have have a distinction between instructions for RELEASE, ACQ_REL and SEQ_CST semantics. The basic problem is that the GCC builtins and atomic instruction semantics were designed for Intel processors that do not provide the level of granularity implemented in POWER processors. The POWER port implemented lighter weight ACQ_REL semantics. Retrofitting the original builtins on the new C++11 memory model semantics and imposing SEQ_CST interpretation has changed the behavior and performance on POWER, but not on other targets.