[PATCH] Add atomic type qualifier

Joseph S. Myers joseph@codesourcery.com
Mon Jul 29 16:12:00 GMT 2013


On Mon, 29 Jul 2013, Andrew MacLeod wrote:

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

Note that you only need *one* of the types to be floating-point for this 
issue to apply.  If you have

_Atomic char c;
float f;

c /= f;

then all the same requirements apply; there may be exceptions to discard 
not just from the division, but from the conversion of a float division 
result to char.

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

I think that's probably OK (though, is this a theorem of the formal 
modelling work that has been done on the memory model?), but note it's not 
just a decl but an arbitrary pointer dereference (the address of the 
lvalue is only evaluated once, no matter how many compare-and-exchange 
operations are needed), and the operation may end up looking like

*ptr = (convert to type of *ptr) ((promote) *ptr op (promote) val)

rather than a simple decl = decl op val.  Or something more complicated if 
the operation involves complex numbers - look at what gets for mixed real 
/ complex arithmetic, for example.  Given

_Atomic _Complex float f;
double d;

f += d;

the atomicity is for the whole complex number (and so the 
compare-and-exchange needs to work on the whole number) although only the 
real part is modified by the addition.

-- 
Joseph S. Myers
joseph@codesourcery.com



More information about the Gcc-patches mailing list