[v3] atomics

[David Daney]

Benjamin Kosnik wrote:
>> 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...

This doesn't work as this is a compile test not a link test.  The 
failure happens at link time as the __sync_lock_test_and_set is expanded 
to a lib call if it cannot be expanded in-line.

I'm sure that a link test could be created, but I think that for mips I 
will just add the patterns so that it works as intended.  I'm not sure 
how other targets will be effected.

David Daney