On Oct 12, 2011, at 6:27 PM, Eli Friedman wrote: > On Wed, Oct 12, 2011 at 6:06 PM, John McCall <[email protected]> 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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
