On 10/18/2013 01:27 PM, Joseph S. Myers wrote:
On Fri, 18 Oct 2013, Andrew MacLeod wrote:
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
I'm thinking of upsizing as something that's best done only for special
cases such as maybe hppa - that the normal case is that if you request a
6-byte atomic object, it's not lock-free. I think users generally expect
to need to choose appropriate types for their atomic operations.
(Indeed, we could even merge without the hook, potentially, on the basis
that atomic_flag is the sole type that needs to be lock-free and so all
that's required is a suitable target-specific definition of that type in
stdatomic.h. And there's a case for not putting the hook on mainline
until it's needed. So maybe the attributes and hook can be completely
avoided on that basis.)
I had thought about making the type and value of atomic_flag hooks , but
never got to it. There is currently one for the TRUE value which is
exposed to the C++ templates as" __GCC_ATOMIC_TEST_AND_SET_TRUEVAL"
It is used to set the type to either bool or unsigned char right now,
and used to set the true value in test_and_set. I thought that should
be fully flushed out so that the type and both the true/false values
were provided by the compiler... and they could be overridden by the
target if they were different than the default...
Seems to me there was a PR or problem vaguely related to this somewhere
that this would resolve as well..
And maybe we could skip most of the rest indefinitely...
The alignment issue is an actual issue on the cris port I think. Their 2
byte atomic operations must operate on 4 byte aligned values... IIRC. I
suspect that can wait for another release to address better. Thats the
only one I'm aware of.
Andrew
Andrew
