This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Future atomic operation cleanup
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, "GNU C. Library" <libc-alpha at sourceware dot org>
- Date: Fri, 22 Aug 2014 14:50:07 +0000
- Subject: Re: Future atomic operation cleanup
- Authentication-results: sourceware.org; auth=none
- References: <53F74A93 dot 30508 at linux dot vnet dot ibm dot com> <53F74CE4 dot 5070809 at twiddle dot net>
On Fri, 22 Aug 2014, Richard Henderson wrote:
> When development opens again, can we simplify all of these atomic operations by
> assuming compiler primitives? That is, use the __atomic builtins for gcc 4.8
> and later, fall back to the __sync builtins for earlier gcc, and completely
> drop support for truly ancient compilers that support neither.
>
> As a bonus we'd get to unify the implementations across all of the targets.
Well, no, we wouldn't - __atomic_* and __sync_* aren't expanded inline on
all targets, and at least we can't depend on libatomic (and I'm not sure
about using out-of-line __sync_* from libgcc.a either). But you could
have a default version of bits/atomic.h defining things in the way you
outline (supporting using __atomic_* with GCC 4.7 as well if desired by
the architecture - MIPS deliberately does that for MIPS16 even though
efficient __atomic_* support on MIPS was only added for 4.8), conditional
on the macros such as __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, and with
architectures only overriding that default to allow for cases where some
of the operations may not be expanded inline by GCC.
(We could also increase the minimum GCC version for building glibc from
4.4 to 4.6 or 4.7 to reduce the number of cases needing consideration of
what compiler support is / is not present.)
--
Joseph S. Myers
joseph@codesourcery.com