On Mon, Feb 27, 2012 at 7:12 AM, Andrew MacLeod <[email protected]> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
