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

[John McCall]

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<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.
> 
> 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.