Why is std :: atomic <double> not implemented when compiling with clang?

Question

Consider the following code snippet:

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

g ++ compiles it just fine, while clang ++ creates the following:

 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) 

Are they associated with the same standard library?

Answer 1

If clang++ -stdlib=libstdc++ does not solve your problem, refer to -latomic to implement these functions.

Try to get your compiler to built-in 8-byte and narrower atoms, though, since library functions have potentially big flaws.

Beware that the library functions do not support a memory order smaller than memory_order_seq_cst , so they always use mfence on x86, even if the source used relaxed .

The x86 __atomic_store_8 32-bit version is even worse: it uses lock cmpxchg8b instead of the 8-byte SSE or x87 storage. This makes it work, even if it is biased, but with a massive decrease in performance. It also has two redundant lock or [esp], 0 instructions lock or [esp], 0 as additional barriers when loading its arguments from the stack. (I look at /usr/lib32/libatomic.so.1.2.0 with gcc7.1.1 on Arch Linux.)

Ironically, the current gcc -m32 (in C11 mode rather than C ++ 11) aligns atomic_llong inside the structure, but inlines movq xmm loads / saves, so it is not actually atomic. ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65146#c4 )

Current clang -m32 aligns atomic_llong to 8 bytes even inside structures (unlike the usual long long , which the i386 System V ABI aligns with only 4B). The irony is that clang generates calls to library functions that uses lock cmpxchg8b , so it is actually atomic even with caching line breaks. ( Why is the integer variable assignment set with natural alignment? So clang is safe even if some gcc-compiled code passes it a pointer to inconsistent _Atomic long long . But it does not agree with gcc about the layout of the structure, so this can only help in the event that it receives a pointer to an atomic variable directly, and not to the containing structure.