This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C11-atomic] Miscellaneous fixes 1/n
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 18 Oct 2013 17:27:12 +0000
- Subject: Re: [C11-atomic] Miscellaneous fixes 1/n
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1310172148110 dot 29273 at digraph dot polyomino dot org dot uk> <52616493 dot 3080301 at redhat dot com>
On Fri, 18 Oct 2013, Andrew MacLeod wrote:
> right. We may re-visit it when we finalize the ABI changes for c++... Use of
> the attribute in c++ will ensure that C and C++ both treat an atomic object
> the same... My original discussions with lawrence and jeffrey over atomics
> concerned the desire to "upsize" an _Atomic object to the next highest size
> that supports lock-free operations. (ie, a 6 byte object becomes an 8 byte
> atomic object). The __attribute__ is really to ensure we can share the code
I'm thinking of upsizing as something that's best done only for special
cases such as maybe hppa - that the normal case is that if you request a
6-byte atomic object, it's not lock-free. I think users generally expect
to need to choose appropriate types for their atomic operations.
(Indeed, we could even merge without the hook, potentially, on the basis
that atomic_flag is the sole type that needs to be lock-free and so all
that's required is a suitable target-specific definition of that type in
stdatomic.h. And there's a case for not putting the hook on mainline
until it's needed. So maybe the attributes and hook can be completely
avoided on that basis.)
--
Joseph S. Myers
joseph@codesourcery.com