This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Transition to C11 atomics and memory model

On Mon, 15 Sep 2014, Torvald Riegel wrote:

> > * 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.

The 64-bit ARM atomics (linux-atomic-64bit.c) rely on kernel helpers that 
are only available in some kernel versions and involve a function called 
at startup to test for availability of those helpers and call __write / 
abort if not available.

I don't know if that would work in all places where glibc uses atomics, 
but I think we should avoid the issue by making sure not to use 64-bit 
atomics at all on 32-bit platforms (and hopefully ensure that such atomics 
produce a compile / link failure if used).

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]