This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Future atomic operation cleanup
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 29 Aug 2014 14:52:26 -0700 (PDT)
- 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> <53FF3551 dot 8020503 at linux dot vnet dot ibm dot com> <1409240266 dot 6045 dot 62 dot camel at triegel dot csb> <53FF5889 dot 5080006 at linux dot vnet dot ibm dot com> <1409306115 dot 6045 dot 71 dot camel at triegel dot csb> <54005FAA dot 9000802 at linux dot vnet dot ibm dot com> <1409318874 dot 6045 dot 73 dot camel at triegel dot csb> <540080DF dot 6030205 at linux dot vnet dot ibm dot com>
I don't see a problem with conditional code based on available compiler
version--that is, conditional code within the atomic.h implementations
themselves. What I take to be the main thrust of Torvald's suggestion is
that we get ASAP to a situation where all the code outside of actual
atomic.h implementations themselves is using a new atomic.h API that has
semantics and signatures identical to, and names similar to, the
C11-supporting builtins. That enables us to clean up, fix, and optimize
all the actual uses of atomics throughout the codebase, without waiting
until we can rely on requiring newer compiler versions throughout.
I tend to think it is still too early to mandate 4.7 or later. I think we
can in the 2.21 cycle move up to 4.6 as the minimum (and 4.8 or
4.9 as the recommended version). But we should discuss that further.