Fixed as of https://reviews.llvm.org/rL298835.

Not only have we removed the runtime dependency on the C++ standard library runtime, but also removed some uses of std::atomic<...> that might prove problematic in some cases.

Fixed as of https://reviews.llvm.org/rL298835.

Not only have we removed the runtime dependency on the C++ standard library
runtime,

That's not guaranteed though, is it? If you use any C++ library features, they might rely on runtime support from some library that needs to be linked in. The one(s) that've been used so far don't appear to, but it doesn't make this solidly portable (granted, there's no guarantee that some compiler doesn't produce binaries that need a C++ runtime support library even if they use no library features at all - but that's perhaps a bit less likely).

I'm not too fussed personally - but suspect that it's probably still right/proper to remove all C++ library dependencies unless there's a way to do what Chandler had mentioned a while back - statically linking in a privately mangled version of the standard library.

but also removed some uses of std::atomic<...> that might prove
problematic in some cases.

Re-opening to reflect the most recent state: we should not be using anything from the C++ standard library. This is based on the conversation we've had in llvm-dev@:

http://lists.llvm.org/pipermail/llvm-dev/2017-October/118126.html

In particular:

"""
The sanitizers don't use any of the C++ std library.
More than that, they don't include any system headers in most of the
sources (exception is some OS-dependent .cc files).

This rule is somewhat documented, e.g.
tsan/rtl/tsan_rtl.h:

// - No system headers included in header files ().
// - Platform specific headres included only into platform-specific files
().
"""

http://lists.llvm.org/pipermail/llvm-dev/2017-October/118132.html

Recent work on this has removed all dependencies to standard library dependencies.

Unfortunately, we're still relying on some C++ specific functionality, some of which are provided by libcxxabi, but I'd like to explore the possibility of removing those first/instead.

This came up in a discussion with why we're failing to link C programs with XRay instrumentation. Reopening this bug so that we can address this in either the runtime, or even in Clang.

This is now fixed by https://reviews.llvm.org/rL334262 (r334262).