Re: [PATCH] Add atomic type qualifier

[Andrew MacLeod <amacleod at redhat dot com>]

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 :-)
> >    * 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
> inline.
>   
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.

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 
form was
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..

Andrew