c++ - 为什么用 clang 编译时 std::atomic 没有实现？

Question

考虑以下代码:

#include <atomic>

int main(void) {
  std::atomic<double> aDouble;
  aDouble = 6.0;
}

G++ 可以很好地编译它，而 clang++ 会生成以下内容:

clang++ -std=c++11 Main.cpp 
/tmp/Main-d4f0fc.o: In function `std::atomic<double>::store(double, std::memory_order)':
Main.cpp:(.text._ZNSt6atomicIdE5storeEdSt12memory_order[_ZNSt6atomicIdE5storeEdSt12memory_order]+0x31): undefined reference to `__atomic_store_8'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

它们是否链接到同一个标准库？

Answer 1

如果 clang++ -stdlib=libstdc++ 不能解决您的问题，请链接到 -latomic 以实现这些功能。

尽管如此，请尝试让您的编译器内联 8 字节和更窄的原子，因为库函数可能存在很大的缺点。

请注意，库函数不支持弱于 memory_order_seq_cst 的内存排序，因此它们总是在 x86 上使用 mfence，即使使用的来源 relaxed。

---

__atomic_store_8 的 32 位 x86 版本更糟:它使用 lock cmpxchg8b 而不是 SSE 或 x87 8 字节存储。这使得它即使在未对齐的情况下也能正常工作，但会造成巨大的性能损失。它还具有两个冗余的 lock 或 [esp], 0 指令作为从堆栈加载其参数的额外障碍。 (我正在查看来自 Arch Linux 上 gcc7.1.1 的 /usr/lib32/libatomic.so.1.2.0。)

具有讽刺意味的是，当前的 gcc -m32(在 C11 模式下，而不是 C++11 下)在结构内欠对齐 atomic_llong，但内联 movq xmm 加载/存储，所以它实际上不是原子的。 ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65146#c4 )

当前的 clang -m32 甚至在结构内部将 atomic_llong 对齐到 8 个字节(不同于常规的 long long，后者 i386 System V ABI 仅对齐到 4B)。具有讽刺意味的是，clang 生成对库函数的调用，它使用 lock cmpxchg8b ( https://bugs.llvm.org/show_bug.cgi?id=33109 ) 所以它实际上是原子的，即使缓存行拆分也是如此。 (Why is integer assignment on a naturally aligned variable atomic on x86?)。

所以 clang 是安全的，即使一些 gcc 编译的代码传递给它一个指向未对齐的 _Atomic long long 的指针。但它不同意 gcc 的结构布局，因此只有当它直接获取指向原子变量的指针而不是包含结构的指针时，这才有帮助。

---

相关:Atomic double floating point or SSE/AVX vector load/store on x86_64