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 jos...@codesourcery.com
