From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-381130-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 22691 invoked by alias); 24 Jan 2012 15:30:54 -0000
Received: (qmail 22682 invoked by uid 22791); 24 Jan 2012 15:30:53 -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, 24 Jan 2012 15:30:41 +0000
From: "dje at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add
Date: Tue, 24 Jan 2012 16:46:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
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: <bug-51798-4-WRBV0Rnx8I@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-51798-4@http.gcc.gnu.org/bugzilla/>
References: <bug-51798-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2012-01/txt/msg02805.txt.bz2

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

--- Comment #5 from David Edelsohn <dje at gcc dot gnu.org> 2012-01-24 15:29:44 UTC ---
Are you suggesting that the existing atomicity support in libstdc++ should be
changed to use ACQ_REL semantics?

libstdc++ uses one function to both acquire and release a lock.  It adds a
positive value (increment) to acquire a lock and a negative value (decrement)
to release a lock.

POWER appears to be the most flexible and delicate platform with respect to
atomic operations and we have been building and testing with my patch for weeks
without problem.  ACQUIRE, RELEASE, ACQ_REL and SEQ_CST does not make a
practical difference in the emitted code on other platforms, so relaxing the
semantics would not cause a problem.