This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Patch, libstdc++] Fix data races in basic_string implementation
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: Dmitry Vyukov <dvyukov at google dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, libstdc++ at gcc dot gnu dot org, Alexander Potapenko <glider at google dot com>, Kostya Serebryany <kcc at google dot com>, Torvald Riegel <triegel at redhat dot com>
- Date: Tue, 1 Sep 2015 16:08:47 +0100
- Subject: Re: [Patch, libstdc++] Fix data races in basic_string implementation
- Authentication-results: sourceware.org; auth=none
- References: <CACT4Y+Yk22UTKyvAD=SCxbMU4SGjra7T1gG7aSikHLbLWxvk1g at mail dot gmail dot com> <20150901142713 dot GG2631 at redhat dot com> <CACT4Y+YTP1SOU-U8E=rxZccHkQTOFAXHgZg6-YZ2tSvsgxfifQ at mail dot gmail dot com>
On 01/09/15 16:56 +0200, Dmitry Vyukov wrote:
I don't understand how a new gcc may not support __atomic builtins on
ints. How it is even possible? That's a portable API provided by
recent gcc's...
The built-in function is always defined, but it might expand to a call
to an external function in libatomic, and it would be a regression for
code using std::string to start requiring libatomic (although maybe it
would be necessary if it's the only way to make the code correct).
I don't know if there are any targets that define __GTHREADS and also
don't support __atomic_load(int*, ...) without libatomic. If such
targets exist then adding a new configure check that only depends on
__atomic_load(int*, ...) would mean we keep supporting those targets.
Another option would be to simply do:
bool
_M_is_shared() const _GLIBCXX_NOEXCEPT
#if defined(__GTHREADS)
+ { return __atomic_load(&this->_M_refcount, __ATOMIC_ACQUIRE) > 0; }
+#else
{ return this->_M_refcount > 0; }
+#endif
and see if anyone complains!