This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Add atomic type qualifier
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, hp at bitrange dot com, Richard Henderson <rth at redhat dot com>
- Date: Mon, 29 Jul 2013 10:59:59 -0400
- Subject: Re: [PATCH] Add atomic type qualifier
- References: <51F2AEB1 dot 60408 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1307281928000 dot 28065 at digraph dot polyomino dot org dot uk>
On 07/28/2013 03:34 PM, Joseph S. Myers wrote:
On Fri, 26 Jul 2013, Andrew MacLeod wrote:
What it doesn't do:
* It doesn't implement the stdatomic.h header - do you intend that to be
provided by GCC or glibc?
(Substantive review of the full patch still to come.)
I figured gcc would provide it... but I hadn't given it a ton of
thought on whether that was good or bad. again, that sort of thing
isn't really my strong suit :-)
Blick. What were they smoking the night before... I guess we'll probably
need to enhance the current atomic patterns in RTL... We should be
able to figure out that its floating point and invoke the appropriate
RTL pattern during expansion rather than an existing one. OR just
frigging call libatomic and let it deal with it. :-) I guess there
wouldnt be any other fallback available. Actually, thats a mess... no
way for the librtary to know its floating point unless you tell it
somehow with new entry points or somesuch.. very lame.
* It doesn't implement the C11 expression expansion into atomic built-ins.
ie, you can't write:
_Atomic int x;
x = 0;
and have the result be an atomic operation calling __atomic_store (&x,
0). That will be in a follow on patch. So none of the expression expansion
from C11 is included yet. This just enables that.
The hardest part will probably be compound assignment to an atomic object
where either operand of the assignment has floating-point type - see C11
footnote 113, but you can't actually use feholdexcept or feclearexcept or
feupdateenv here because that would introduce libm dependencies, so back
ends will need to provide appropriate insn patterns to do those operations
I planned to do the work in gimplification... let the atomic decls
through, and during gimplification, loads or stores of an atomic decl
would be converted to the appropriate load or store builtin, and at the
same time recognize the 'decl = decl op value' expression and replace
those as appropriate with atomic_op_fetch operations. I had discussed
this at some length with Lawrence crowl and Jeffrey Yasskin some time
ago.. At gimplification time we no longer know whether the original
decl op= val or decl = decl op val;, but the decision was that it is ok
to recognize decl = decl op val and make that atomic.. it would still
satisfy the language requirements..