[cfe-commits] [PATCH] atomic operation builtins, part 1

[John McCall]

On Oct 12, 2011, at 6:27 PM, Eli Friedman wrote:
> On Wed, Oct 12, 2011 at 6:06 PM, John McCall <rjmccall at apple.com> wrote:
>> On Oct 12, 2011, at 2:54 PM, Andrew MacLeod wrote:
>>> I'm still not sure I see how it matters. Nothing should ever access or change that padding field in an unfriendly way since it is always part of the atomic word that is load/stored, exchanged or compare_exchanged. Those are the only 4 ways to access the memory.  All the fetch_op's only operate on full integral values, so thats not a concern.   Compare_exchange is the only one which it could be affected, and it requires that the 'expected' value be from an atomic load or exchange…
>> 
>> I wasn't aware of that.  That's really a very strange constraint — why is it illegal to independently assemble a value that I expect might be in an atomic variable?
> 
> The standard doesn't make any guarantees about the layout of
> std::atomic<T>; how exactly could you manipulate the bits of an
> std::atomic<T> in a cross-platform manner?

You couldn't, but that's not what I said.  I'm saying that it's strange
that the expected value of a compare & exchange is apparently
not permitted to be a T that I've constructed in an arbitrary way;
it has to be a T that I've read with an atomic load or exchange.

Anyway, it doesn't make a difference, because the T I read out of
the atomic load/exchange will obviously not carry along the extra
padding from the atomic<T>.

John.