Re: Transition to C11 atomics and memory model

[Torvald Riegel <triegel at redhat dot com>]

On Mon, 2014-09-15 at 16:51 +0000, Joseph S. Myers wrote:
> On Sun, 14 Sep 2014, Torvald Riegel wrote:
> 
> > 1) Add new C11-like atomics.  If GCC supports them on this architecture,
> > use GCC's atomic builtins.  Make them fall back to the existing atomics
> > otherwise.  Attached is a small patch that illustrates this.
> 
> I'm not clear on how you propose to determine whether to define 
> USE_ATOMIC_COMPILER_BUILTINS.

Yes, sorry for leaving that unspecified.  I intended this flag to be
arch-specific, not a global setting; in fact, the comments you
previously made on the subject motivated that.

We can handle most of the transition to C11 atomics in a
non-arch-specific way (because the memory model itself is portable).
But for the arch-specific changes I'd really appreciate input / help
from the machine maintainers.

> * In some cases those macros are defined by GCC even though the operations 
> are out of line in libgcc.  On PA the HAVE_sync_compare_and_swap* macros 
> are defined in pa-linux.h to cause __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* to 
> be predefined; for Tile GCC has special target-specific code to define 
> __GCC_HAVE_SYNC_COMPARE_AND_SWAP_*.  Do we believe such out-of-line libgcc 
> versions will work in glibc, and is it preferable to use them or inline 
> asm?  (My guess is that they might work except for cases such as the 
> 64-bit ARM atomics with references to libc interfaces.)

I believe they should work from a correctness perspective, but might
have a slight performance disadvantage.  I'm not sure I understand the
ARM case you mention.