[cfe-commits] [libcxx] r115633 - /libcxx/trunk/www/atomic_design.html
John McCall
rjmccall at apple.com
Tue Oct 5 10:55:50 PDT 2010
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.
More information about the cfe-commits
mailing list