This is the mail archive of the libc-alpha@sourceware.org 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: Purpose of USE_ATOMIC_COMPILER_BUILTINS


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


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