On 10/17/2013 05:50 PM, Joseph S. Myers wrote:
I've applied this patch to the C11-atomic branch to fix various
miscellaneous issues.
excellent!
I put a hack in the C++ front end to disable checks on atomic
qualifiers so that libstdc++ builds - I think that if you want other
people to help on a development branch, it should be kept in a state
where it builds and tests cleanly. However, I'm aiming specifically
Yes, perhaps I should not have checked in the bit that uses the atomic
attribute in the c++ templates... it was working fine until late in the
game when I removed the incorrect "treat atomic as volatile" parts of
the patches.. which then caused that failure. sorry. I didn't know how
to fix it "correctly"... I figured it should be easy if you knew how
:-P but maybe not...
to sort out the C front-end (and later stdatomic.h) issues, with a
view to getting the actual C11 support in shape and with adequate
testsuite coverage, so if that's ready on time I may propose it for
mainline without the attribute or C++ changes - as I understand it,
those are only needed for when targets start defining atomic types as
larger or more-aligned than the corresponding non-atomic types, not to
support the C11 features on the most common architectures.
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 and get compatible behaviour
between languages. At the moment it is a nop. A better solution may
show up, if we ever actually need it.
Thanks for picking this up... I for one really appreciate it.
Andrew
