[Bug libstdc++/51798] New: [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[Bug libstdc++/51798] New: [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[dje at gcc dot gnu.org]

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

             Bug #: 51798
           Summary: [4.7 regression] libstdc++ atomicity performance
                    regression due to __sync_fetch_and_add
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dje@gcc.gnu.org


libstdc++ uses __sync_fetch_and_add() to provide atomicity for reference
counting.  The semantics of __sync_fetch_and_add() were not explicitly stated. 
libstdc++ apparently requires ACQUIRE semantics for incrementing the reference
count and RELEASE semantics for decrementing the reference and possibly
destroying the object.  The libstdc++ code did not make this distinction, but
__sync_fetch_and_add() generally was implemented as RELEASE semantics, which
was overkill for increment and appropriate for decrement/destroy.

As part of the C++11 memory model changes, __sync_fetch_and_add() atomicity was
changed to use the new, more general atomicity infrastructure with SEQUENTIAL
CONSISTENCY.  This imposes the most strict and heavy-weight barrier.

On architectures with granularity and gradations in the implementation of
atomic instructions, this introduces a severe performance regression.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[dje at gcc dot gnu.org]

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

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-01-09
                 CC|                            |bergner at gcc dot gnu.org
      Known to work|                            |4.6.0, 4.6.1
           See Also|                            |http://gcc.gnu.org/bugzilla
                   |                            |/show_bug.cgi?id=51766
     Ever Confirmed|0                           |1
      Known to fail|                            |4.7.0

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[dje at gcc dot gnu.org]

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

--- Comment #1 from David Edelsohn <dje at gcc dot gnu.org> 2012-01-09 14:37:35 UTC ---
Proposed patch:
http://gcc.gnu.org/ml/libstdc++/2012-01/msg00044.html

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
                 CC|                            |rth at gcc dot gnu.org
   Target Milestone|---                         |4.7.0

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-09 15:42:35 UTC ---
Related to PR51766.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn <dje at gcc dot gnu.org> 2012-01-09 17:11:32 UTC ---
Another alternative is to modify __gnu_cxx::_atomic_add() to perform acquire
semantics for positive increments and release semantics for negative
increments.  That avoid creating a new function in the __gnu_cxx space.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bkoz at redhat dot com

--- Comment #4 from Andrew Macleod <amacleod at redhat dot com> 2012-01-24 05:41:43 UTC ---
Looking at the old sync.md and rs6000.c files, it looks to me like
sync_fetch_and_add always issued a lwsync before the operation and an isync
afterwards.  

With the new atomics, it looks like making these fetch_and_add operations use
acq_rel mode, we'd get exactly the same code.  I suspect it would be safe to
convert those uses in atomicity.h to acq_rel.  If acq_rel wasn't sufficient,
power would likely have had a defect somewhere over the years...  

At least that would appear to be safe(r) to me on the surface...  And it would
return the missing performance?  I'd be more hesitant about relaxing the mode
any further than that.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[dje at gcc dot gnu.org]

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.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[amacleod at redhat dot com]

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

--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> 2012-01-24 16:02:03 UTC ---
Others expressed concern about a change that could potentially affect all
targets since its in libstdc++ code, especially considering this code is being
deprecated.  There are targets other than power that are also sensitive to the
new semantics, both arm and alpha will change barrier emission based on the
model used in fetch_and_add.

I suggest acq-rel simply because it produces the same barrier structure power
had in previous releases, is less intrusive, and is less likely to have an
additional unforeseen impact anywhere else (other targets will also get the
same barriers they had I believe.)  You should see the same performance you had
before wouldn't you?

Im not arguing that using just release and acquire semantics instead wouldn't
also be correct, merely that it is harder to prove the semantic change won't
have unforeseen side effects in someones code.   Its possible that relaxed mode
might be also good enough, but again, harder to prove and comes with even
greater risk. 

Anyway, just providing an option. It the libstdc++ guys that have to make the
decision :-)

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-25 14:08:41 UTC ---
At least at this point I'd feel much safer if libstdc++ used just acq_rel
semantics for the all atomic_fetch_and_add places, instead of somewhere acq and
somewhere rel semantics.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[dje at gcc dot gnu.org]

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

--- Comment #8 from David Edelsohn <dje at gcc dot gnu.org> 2012-01-25 15:14:29 UTC ---
> At least at this point I'd feel much safer if libstdc++ used just acq_rel
> semantics for the all atomic_fetch_and_add places, instead of somewhere acq and
> somewhere rel semantics.

Can we at least apply the ACQ_REL patch using the new atomic intrinsics?

Unfortunately, without my patch, libstdc++ users of atomicity.h (basic_string,
shared_ptr) do not distinguish between ACQUIRE and RELEASE, so POWER cannot
provide its own atomicity.h with the improved implementation.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[amacleod at redhat dot com]

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

--- Comment #9 from Andrew Macleod <amacleod at redhat dot com> 2012-01-25 15:36:23 UTC ---
(In reply to comment #8)
> > At least at this point I'd feel much safer if libstdc++ used just acq_rel
> > semantics for the all atomic_fetch_and_add places, instead of somewhere acq and
> > somewhere rel semantics.
> 
> Can we at least apply the ACQ_REL patch using the new atomic intrinsics?
> 

Well, I thought that was implicit since I wasn't suggesting we change the
__sync semantics, just the required libstdc++ bits.  

All that has to be done is replace the two __sync_fetch_and_add(...) with
__atomic_fetch_add(.., __ATOMIC_ACQ_REL)  in atomicity.h isn't it?

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[dje at gcc dot gnu.org]

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

--- Comment #10 from David Edelsohn <dje at gcc dot gnu.org> 2012-01-25 15:43:51 UTC ---
> All that has to be done is replace the two __sync_fetch_and_add(...) with
> __atomic_fetch_add(.., __ATOMIC_ACQ_REL)  in atomicity.h isn't it?

In src/libstdc++-v3/include/ext/atomicity.h and in
src/libstdc++-v3/config/cpu/generic/atomicity_builtins/atomicity.h

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-26 13:01:58 UTC ---
What about the other files that use __sync_* in libstdc++?
include/tr1/shared_ptr.h, include/bits/shared_ptr_base.h,
include/profile/impl/profiler_state.h, libsupc++/guard.cc and parts of
include/parallel/compatibility.h use __sync_*compare_and_swap or
__sync_lock_test_and_set, so I assume that we have the same code for those on
ppc* as before, but in
include/parallel/compatibility.h, libsupc++/eh_tm.cc, libsupc++/eh_ptr.cc and
libsupc++/eh_throw.cc __sync_*fetch* is used.  Should we change all those to
use acq_rel semantics __atomic* counterparts in addition to
include/ext/atomicity.h and config/cpu/generic/atomicity_builtins/atomicity.h?

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[amacleod at redhat dot com]

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

--- Comment #12 from Andrew Macleod <amacleod at redhat dot com> 2012-01-26 13:57:56 UTC ---
(In reply to comment #11)
> What about the other files that use __sync_* in libstdc++?

I would change the bare minimum... Every change is a risk of some sort this
late n the game.   The only reason to consider this change was the unacceptable
performance regression on power which was reported.   If it hasn't been
reported, I'd leave it alone personally :-)

I hope to replace *all* __sync calls everywhere in the toolchain with __atomic
for 4.8. That way there is also time to evaluate the proper model for each one
and test it.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[dje at gcc dot gnu.org]

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

--- Comment #13 from David Edelsohn <dje at gcc dot gnu.org> 2012-01-26 15:02:14 UTC ---
If libstdc++-v3 does not consistently use its own atomicity.h everywhere, then
it is even more broken.  Any code that explicitly calls __sync_* in
libstdc++-v3 has introduced a performance regression.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-26 15:25:11 UTC ---
(In reply to comment #13)
> If libstdc++-v3 does not consistently use its own atomicity.h everywhere, then
> it is even more broken.

calm down, a few places in libstdc++ use __sync_compare_and_swap directly
because there is no CAS in atomicity.h

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[dje at gcc dot gnu.org]

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

--- Comment #15 from David Edelsohn <dje at gcc dot gnu.org> 2012-01-26 19:42:47 UTC ---
> calm down, a few places in libstdc++ use __sync_compare_and_swap directly
> because there is no CAS in atomicity.h

Jonathan,

I do not know what you are reading into my comment.  This has nothing to do
with calmness, it is a statement of fact.  If more places in libstdc++ use
__sync intrinsics directly, then more places have regressed. It is unfortunate
that the current implementation of libstdc++ did not localize the use of those
intrinsics.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-26 20:39:40 UTC ---
Apologies for my phrasing.  What I meant is that it's not a matter of
consistency.

Localising all uses of __sync_bool_compare_and_swap by adding an unnecessary
additional layer of indirection in atomicity.h would not have been appropriate.
 GCC already abstracts the required CAS operation with
__sync_bool_compare_and_swap, so that is used directly when needed.  One of the
main reasons for the wrappers in atomicity.h is to fall back to non-atomic ops
in non-threaded code, rather than just to localize the use of intrinisics.
Having a fall back for non-threaded code isn't necessary for the places where
__sync_bool_compare_and_swap is used in shared_ptr and parallel mode. Our
shared_ptr has a partial specialization for the non-threaded case, which
doesn't use CAS, and using parallel mode in non-threaded code doesn't make
sense.  So __sync_bool_compare_and_swap is used directly. "It's own
atomicity.h" doesn't include a CAS operation, and I see no benefit to adding
CAS to that file.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-27 09:33:11 UTC ---
(In reply to comment #13)
> Any code that explicitly calls __sync_* in
> libstdc++-v3 has introduced a performance regression.

But if it happens in code that is executed only rarely (e.g. the EH code will
be dominated by time spent in the unwinder, not any barriers), then it might
not be even measurable.  So I think we should first change atomicity.h and only
if you can come up with a testcase which shows a significant regression for the
libsupc++ or parallel bits, we should change those too at this point.  We are
in stage4.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-27 11:17:35 UTC ---
Created attachment 26480
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26480
gcc47-pr51798.patch

This is one of the few remaining P1s, so in order to speed this up, is this
patch what we are considering now?  If yes, I'll go ahead and test it on
i?86/x86_64/ppc/ppc64/s390/s390x.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[amacleod at redhat dot com]

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

--- Comment #19 from Andrew Macleod <amacleod at redhat dot com> 2012-01-27 12:49:27 UTC ---
(In reply to comment #17)
> (In reply to comment #13)
> > Any code that explicitly calls __sync_* in
> > libstdc++-v3 has introduced a performance regression.
> 
> But if it happens in code that is executed only rarely (e.g. the EH code will
> be dominated by time spent in the unwinder, not any barriers), then it might
> not be even measurable.  So I think we should first change atomicity.h and only
> if you can come up with a testcase which shows a significant regression for the
> libsupc++ or parallel bits, we should change those too at this point.  We are
> in stage4.

Precisely my thoughts... Its not a regression if it isn't measurable, and we
want to change as little as we possibly can at this stage.  The patch is what I
was thinking.  

I presume it generates the same code power use to get?

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[dje at gcc dot gnu.org]

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

--- Comment #20 from David Edelsohn <dje at gcc dot gnu.org> 2012-01-27 14:27:25 UTC ---
Jonathan,

Your explanation in comment #16 does not fully explain the design of
libstdc++-v3.  If the __sync_* intrinsics provide the complete abstraction for
CAS, what is the purpose of the custom implementations of atomicity.h in
libstdc++-v3/config/{cpu,os}/* ?  One should not need those overrides if
__sync_* provides sufficient abstraction.

Jakub,

The patch is incomplete because it should update
src/libstdc++-v3/config/cpu/generic/atomicity_builtins/atomicity.h as well.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-27 14:49:12 UTC ---
(In reply to comment #20)
> The patch is incomplete because it should update
> src/libstdc++-v3/config/cpu/generic/atomicity_builtins/atomicity.h as well.

It does update even that file.
The patch attached here doesn't work though, but with
sed -i -e s/__atomic_fetch_and_add/__atomic_fetch_add/g gcc47-pr51798.patch
it does, so far bootstrap/regression tested on x86_64-linux, i686-linux and
bootstrap tested on {powerpc{,64},s390{,x}}-linux, regression testing on those
4 ongoing.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[dje at gcc dot gnu.org]

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

--- Comment #22 from David Edelsohn <dje at gcc dot gnu.org> 2012-01-27 14:57:42 UTC ---
You're right, the patch does modify both files.  sorry.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[bkoz at gcc dot gnu.org]

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

Benjamin Kosnik <bkoz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bkoz at gcc dot gnu.org

--- Comment #23 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2012-01-27 19:10:49 UTC ---

Jakub, your patch is exactly correct. If your testing succeeds, please check it
in.

Furthermore, I agree with your comment #11. I'm on it.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[jakub at gcc dot gnu.org]

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

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-27 20:26:12 UTC ---
Author: jakub
Date: Fri Jan 27 20:26:03 2012
New Revision: 183644

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183644
Log:
    PR libstdc++/51798
    * config/cpu/generic/atomicity_builtins/atomicity.h
    (__exchange_and_add, __atomic_add): Use __atomic_fetch_add
    with __ATOMIC_ACQ_REL semantics instead of __sync_fetch_and_add.
    * include/ext/atomicity.h (__exchange_and_add, __atomic_add):
    Likewise.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/config/cpu/generic/atomicity_builtins/atomicity.h
    trunk/libstdc++-v3/include/ext/atomicity.h

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-27 20:44:09 UTC ---
Fixed.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[bkoz at gcc dot gnu.org]

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

--- Comment #26 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2012-02-09 08:45:10 UTC ---
Created attachment 26620
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26620
complete transition to __atomic, modulo config


... and for config, plan would be to just remove check for atomic builtins and
resulting macros

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[redi at gcc dot gnu.org]

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

--- Comment #27 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-09 09:16:11 UTC ---
Nice.  Now that we have an atomic load we can also do:

--- a/libstdc++-v3/include/bits/shared_ptr_base.h
+++ b/libstdc++-v3/include/bits/shared_ptr_base.h
@@ -193,7 +193,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
       {
         // No memory barrier is used here so there is no synchronization
         // with other threads.
-        return const_cast<const volatile _Atomic_word&>(_M_use_count);
+        return __atomic_load_n(&_M_use_count, __ATOMIC_RELAXED);
       }

     private:

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[bkoz at gcc dot gnu.org]

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

Benjamin Kosnik <bkoz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #26620|0                           |1
        is obsolete|                            |

--- Comment #28 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2012-02-09 20:07:29 UTC ---
Created attachment 26632
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26632
try two, check cleanups + jonathan's addition

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[bkoz at gcc dot gnu.org]

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

--- Comment #29 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2012-02-09 23:21:51 UTC ---
Created attachment 26635
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26635
complete transition to __atomic, v3


All bits in

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[bkoz at gcc dot gnu.org]

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

--- Comment #30 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2012-02-10 18:20:50 UTC ---
Author: bkoz
Date: Fri Feb 10 18:20:43 2012
New Revision: 184110

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184110
Log:
2012-02-10  Benjamin Kosnik  <bkoz@redhat.com>
            Jonathan Wakely  <jwakely.gcc@gmail.com>

    PR libstdc++/51798 continued.
    * acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Use __atomic_*
    builtins instead of __sync_* builtins for atomic functionality.
    * include/bits/shared_ptr_base.h: Same.
    * include/parallel/compatibility.h: Same.
    * include/profile/impl/profiler_state.h: Same.
    * include/tr1/shared_ptr.h: Same.
    * libsupc++/eh_ptr.cc: Same.
    * libsupc++/eh_throw.cc: Same.
    * libsupc++/eh_tm.cc: Same.
    * libsupc++/guard.cc: Same.
    * configure: Regenerated.
    * testsuite/20_util/shared_ptr/cons/43820_neg.cc: Adjust line numbers.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/acinclude.m4
    trunk/libstdc++-v3/configure
    trunk/libstdc++-v3/include/bits/shared_ptr_base.h
    trunk/libstdc++-v3/include/parallel/compatibility.h
    trunk/libstdc++-v3/include/profile/impl/profiler_state.h
    trunk/libstdc++-v3/include/tr1/shared_ptr.h
    trunk/libstdc++-v3/libsupc++/eh_ptr.cc
    trunk/libstdc++-v3/libsupc++/eh_throw.cc
    trunk/libstdc++-v3/libsupc++/eh_tm.cc
    trunk/libstdc++-v3/libsupc++/guard.cc
    trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/43820_neg.cc
   
trunk/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/cons/43820_neg.cc

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[rth at gcc dot gnu.org]

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

--- Comment #31 from Richard Henderson <rth at gcc dot gnu.org> 2012-02-13 21:30:42 UTC ---
Author: rth
Date: Mon Feb 13 21:30:31 2012
New Revision: 184171

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184171
Log:
PR libstdc++/51798 continued
    * include/bits/shared_ptr_base.h
    (_Sp_counted_base<_S_atomic>::_M_add_ref_lock): Hoist initial load
    outside compare_exchange loop.
    * include/tr1/shared_ptr.h: Same.
    * include/parallel/compatibility.h (__compare_and_swap_32): Use strong
    version of compare_exchange.
    (__compare_and_swap_64): Same.
    * include/profile/impl/profiler_state.h (__gnu_profile::__turn): Same.
    * libsupc++/guard.cc (__cxa_guard_acquire): Same.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/bits/shared_ptr_base.h
    trunk/libstdc++-v3/include/parallel/compatibility.h
    trunk/libstdc++-v3/include/profile/impl/profiler_state.h
    trunk/libstdc++-v3/include/tr1/shared_ptr.h
    trunk/libstdc++-v3/libsupc++/guard.cc

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[bkoz at gcc dot gnu.org]

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

--- Comment #32 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2012-02-17 20:52:04 UTC ---
Author: bkoz
Date: Fri Feb 17 20:51:58 2012
New Revision: 184350

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184350
Log:
2012-02-17  Benjamin Kosnik  <bkoz@redhat.com>

    PR libstdc++/51798 continued.
    * acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Grep for
    __atomic_, not __sync.
    * configure: Regenerated.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/acinclude.m4
    trunk/libstdc++-v3/configure