This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Purpose of USE_ATOMIC_COMPILER_BUILTINS
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 16 Nov 2015 18:30:38 +0000
- Subject: Re: Purpose of USE_ATOMIC_COMPILER_BUILTINS
- Authentication-results: sourceware.org; auth=none
- References: <5649F832 dot 7000001 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1511161758300 dot 30498 at digraph dot polyomino dot org dot uk> <564A1C64 dot 8010008 at redhat dot com>
On Mon, 16 Nov 2015, Florian Weimer wrote:
> On 11/16/2015 07:02 PM, Joseph Myers wrote:
> > On Mon, 16 Nov 2015, Florian Weimer wrote:
> >
> >> What is the USE_ATOMIC_COMPILER_BUILTINS? Is it still needed now that
> >> we require GCC 4.7 or later to compile glibc?
> >
> > Yes. glibc can't use out-of-line functions from libatomic, since
> > libatomic can only be built after glibc. (Out-of-line functions from
> > libgcc are OK if it's considered they don't involve performance issues on
> > a particular processor. Built-in functions might generate calls to either
> > libgcc or libatomic.) The macro says whether it's known for a given
> > architecture that the __atomic_* built-in functions are suitable both
> > regarding correctness (not generating calls to libatomic functions for the
> > glibc use cases) and performance.
>
> Thanks for the explanation, but I can't say I like this situation.
>
> What do I have to do if I want to add atomic sub-and-fetch with
> acquire-release semantics? Should I simply use CAS instead?
I don't have advice on the specifics of what operations are or are not
portably available in glibc, given the need to fall back to things other
than __atomic_*. But the general goal is to move glibc's internal atomics
macros towards C11 semantics, while not necessarily being implemented in
terms of __atomic_* on all architectures; if some architectures or generic
fallbacks fail to follow the appropriate documented memory order for the
glibc macro in question, those architectures or fallbacks should be fixed.
We have, for example, atomic_fetch_add_* for various memory orders - if
one of those does the wrong thing in some cases, that needs to be fixed.
Older macros whose memory orders are unclear should be phased out.
> If this is too much work, would it be easier to compile libatomic before
> glibc instead?
libatomic depends on pthread.h and -lpthread. And there's no
-static-libatomic option. I don't think using libatomic in glibc is
practical.
--
Joseph S. Myers
joseph@codesourcery.com