is_lock_free() 升级到 MacPorts gcc 7.3 后返回 false
is_lock_free() returned false after upgrading to MacPorts gcc 7.3
以前，对于 Apple LLVM 9.1.0，128 位结构上的 is_lock_free() 已返回 true。为了获得完整的 std::optional 支持，我随后升级到 MacPorts gcc 7.3。在我第一次尝试编译时，我遇到了这个臭名昭著的 showstopper linker 错误：
Undefined symbols for architecture x86_64:
"___atomic_compare_exchange_16", referenced from:
我知道我可能需要添加 -latomic。使用 Apple LLVM 9.1.0，我不需要它，对此我有一种非常糟糕的预感。如果它是无锁的，你通常不需要 link 任何额外的库，编译器本身就能处理它。否则，它可能只是基于锁的，需要额外库的支持。正如我担心的那样，添加 -latomic 后，构建成功，但 is_lock_free() 返回 false。
我确实认为 gcc 7.3 及其标准库实现很好。这可能只是我这边的一些配置问题。事实上，我没有做任何配置。我只是安装了 MacPorts gcc 并完成了。知道我可能遗漏了什么吗？
自己找到了答案。
gcc7 and later will call libatomic instead of inlining lock cmpxchg16b, and will return false from atomic_is_lock_free (for reasons including that it's so slow it's not what users expect is_lock_free to mean), but at least for now the libatomic implementation still uses lock cmpxchg16b on targets where that instruction is available. (It can even segfault for read-only atomic objects, so it's really not ideal.)
以前，对于 Apple LLVM 9.1.0，128 位结构上的 is_lock_free() 已返回 true。为了获得完整的 std::optional 支持，我随后升级到 MacPorts gcc 7.3。在我第一次尝试编译时，我遇到了这个臭名昭著的 showstopper linker 错误：
Undefined symbols for architecture x86_64:
"___atomic_compare_exchange_16", referenced from:
我知道我可能需要添加 -latomic。使用 Apple LLVM 9.1.0，我不需要它，对此我有一种非常糟糕的预感。如果它是无锁的，你通常不需要 link 任何额外的库，编译器本身就能处理它。否则，它可能只是基于锁的，需要额外库的支持。正如我担心的那样，添加 -latomic 后，构建成功，但 is_lock_free() 返回 false。
我确实认为 gcc 7.3 及其标准库实现很好。这可能只是我这边的一些配置问题。事实上，我没有做任何配置。我只是安装了 MacPorts gcc 并完成了。知道我可能遗漏了什么吗？
自己找到了答案
gcc7 and later will call libatomic instead of inlining
lock cmpxchg16b, and will return false fromatomic_is_lock_free(for reasons including that it's so slow it's not what users expectis_lock_freeto mean), but at least for now the libatomic implementation still useslock cmpxchg16bon targets where that instruction is available. (It can even segfault for read-only atomic objects, so it's really not ideal.)