This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] atomics
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: David Daney <ddaney at avtrex dot com>
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, crowl at google dot com, Richard Sandiford <rsandifo at nildram dot co dot uk>
- Date: Fri, 18 Apr 2008 13:15:57 -0500
- Subject: Re: [v3] atomics
- References: <20080410152950.4421fda9@wabash.artheist.org> <4808DFA5.2040903@avtrex.com>
> The problem is that MIPS only supports atomic operations on 32 bit
> wide locations (and 64 for mips64). src/atomic.cc appears to be
> trying to generate code for operations on 8 bit wide locations thus
> generating calls to __sync_lock_test_and_set_1 as the operation can
> not be expanded. Since there is no __sync_lock_test_and_set_1
> anything that links against libstdc++.so fails to link (most of the
> c++ and libstdc++ testsuite for example).
I see.
The problem is that _GLIBCXX_ATOMIC_BUILTINS is defined, so that
the __sync_* builtin path is used in atomic.cc.
However, in acinclude.m4's GLIBCXX_ENABLE_ATOMIC_BUILTINS, the use of
__sync_lock_test_and_set(&(__a->_M_base._M_b), 1);
is not tested, only
// NB: _Atomic_word not necessarily int.
typedef int atomic_type;
atomic_type c1;
atomic_type c2;
const atomic_type c3(0);
if (__sync_fetch_and_add(&c1, c2) == c3)
So, adding something like:
Index: acinclude.m4
===================================================================
--- acinclude.m4 (revision 134441)
+++ acinclude.m4 (working copy)
@@ -2288,6 +2288,11 @@
{
// Do something.
}
+
+ typedef bool atomic_bool;
+ atomic_bool b1;
+ __sync_lock_test_and_set(&b1, 1);
+
return 0;
}
Will fix it in configure, at the expense of all other atomic builtins
used by libstdc++ on mips...
-benjamin