On Oct 13, 2011, at 6:22 AM, Andrew MacLeod wrote: > On 10/12/2011 09:40 PM, John McCall wrote: >> 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. > > 1) > Actually, the generic interface breaks if the atomic type is not the same > size as the base type. > > void __atomic_exchange (size_t size, void *ptr, void *expected, void > *desired,...); > > in reality, from GCC's point of view, it currently doesn't distinguish an > atomic type from the base type, it just sees: > void __atomic_exchange(T *ptr, T *expected, T *desired, …) > > if 'expected' and 'desired' were different sizes than 'ptr', we'd need > another size parameter and have to deal with padding code, and I'm not > prepared to go down that road just yet.
I'm not sure why you're implementing this intrinsic without having _Atomic types yet. The intrinsic should really be taking an _Atomic(T)* and two Ts. That also conveniently removes the need for a size parameter. Obviously, it's your call, but… John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
