[cfe-commits] [libcxx] r115633 - /libcxx/trunk/www/atomic_design.html

[John McCall]

On Oct 5, 2010, at 10:22 AM, Howard Hinnant wrote:
> Author: hhinnant
> Date: Tue Oct  5 12:22:28 2010
> New Revision: 115633
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=115633&view=rev
> Log:
> A compiler writer's guide to <atomic>, minor update
> 
> Modified:
>    libcxx/trunk/www/atomic_design.html
> 
> Modified: libcxx/trunk/www/atomic_design.html
> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/atomic_design.html?rev=115633&r1=115632&r2=115633&view=diff
> ==============================================================================
> --- libcxx/trunk/www/atomic_design.html (original)
> +++ libcxx/trunk/www/atomic_design.html Tue Oct  5 12:22:28 2010
> @@ -377,11 +377,17 @@
> <p>
> On some platforms, the compiler vendor can offer some or even all of the above
> intrinsics at one or more weaker levels of memory synchronization.  This might
> -lead for example to not issuing an <tt>mfense</tt> instruction on the x86.  If
> -the compiler does not offer any given operation, at any given memory ordering
> +lead for example to not issuing an <tt>mfense</tt> instruction on the x86.
> +</p>

"mfence"

The design seems reasonable to me.

Have you considered how to support TR18037 address space-qualified pointers?  I assume <atomic> does a reinterpret_cast to void** to use the generic intrinsic, but this can silently do the wrong thing for AS-qualified pointers, which are not necessarily the same size as a generic pointer.  Fortunately, I don't think that happens for any Apple-supported platforms.

John.