================
Comment at: include/__atomic:85
@@ +84,3 @@
+{
+ *__dest = __val;
+}
----------------
EricWF wrote:
> jroelofs wrote:
> > Should these fall back on the __sync_* ones instead of just dropping the
> > atomicness? It seems a little precarious to silently default to non-atomic
> > implementations for these (unless this is for a single-threaded build of
> > the library).
> Yes and no. The only atomic operations needed in the headers are relaxed
> atomic loads. AFAIK all loads are relaxed atomic loads on x86 so not using
> atomic builtins isn't a big deal (its what we already do).
>
> The rest of the atomic operations happen within the dylib. I agree we don't
> want to drop the atomicness on these unless it is a single threaded build.
>
> What we really should do is limit the libc++ dylib build to compilers that
> provide the required atomic intrinsics (single-threaded builds not
> withstanding). If the compiler is not supported then the build should fail.
> For GCC and Clang the required versions would be 4.7 and 3.3 (possibly lower)
> respectively.
>
> Since most of the stuff in `__atomic` is only used in the dylib build perhaps
> it should be moved out of the shipped headers. I'll figure out how to handle
> that tomorrow.
> AFAIK all loads are relaxed atomic loads on x86 so not using atomic builtins
> isn't a big deal
What about PPC-darwin?
> What we really should do is limit the libc++ dylib build to compilers that
> provide the required atomic intrinsics (single-threaded builds not
> withstanding)
Agreed.
http://reviews.llvm.org/D10406
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
