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

[Eli Friedman]

On Mon, Feb 27, 2012 at 7:12 AM, Andrew MacLeod <amacleod at redhat.com> wrote:
> On 02/24/2012 09:24 PM, Girkar, Milind wrote:
>>
>> This does make the size/alignment of the atomic type different from the unqualified type - can somebody highlight the disadvantages due to this difference?
> The only thing I can think of is maybe casting.  Casting from a smaller
> object to a larger atomic object could become problematic since the
> atomic may access more memory than the unqualified type has allocated.
>   Casting from atomic to unqualified should be OK as long as the
> padding is at the end of the atomic object.   Does C11 have any rules
> about casting to/from an Atomic?

C11 doesn't require any specific relationship between the memory
layout of an _Atomic type and the related non-_Atomic type, as far as
I know.  The disadvantage would only be if we want to allow unportable
code that casts a pointer-to-non-_Atomic to pointer-to-_Atomic.

> I don't think padding issues apply to arithmetic objects since we only
> support 1,2,4,8 and 16 byte objects.  ie, we dont have to worry about a
> 3 byte atomic_fetch_add operating on a 4 byte padded value (which is
> effectively left shifted 8 bits).   Will that always be true?  It's
> probably not an issue...

Maybe x86 long double (which is usually 12 bytes on x86-32)?  Besides
that, though, even if padding doesn't apply, alignment can: long long
is commonly 4-byte aligned on 32-bit platforms, but we really want
_Atomic(long long) to be 8-byte aligned, especially on ARM.

-Eli