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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
