is_lock_free() returned false after upgrading to MacPorts gcc 7.3

别说谁变了你拦得住时间么 提交于 2020-01-10 05:05:26

问题


Previously, with Apple LLVM 9.1.0, is_lock_free() on 128-bit structures have returned true. To have complete std::optional support, I then upgraded to MacPorts gcc 7.3. During my first try to compile, I encountered this notorious showstopper linker error:

Undefined symbols for architecture x86_64:
  "___atomic_compare_exchange_16", referenced from:

I know that I may need to add -latomic. With Apple LLVM 9.1.0, I don't need it, and I have a very bad feeling about this. If it's lock-free, you usually should not need to link to any additional library, the compiler alone is able to handle it. Otherwise, it may just be lock-based and require support from additional library. Just as I have feared, after adding -latomic, build succeeded, but is_lock_free() returned false.

I do think gcc 7.3 and its standard library implementation are fine. It may just be some configuration problem on my side. As a matter of fact, I didn't do any configuration. I simply installed the MacPorts gcc and done. Any idea what I may be missing?


回答1:


Found the answer myself here.

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.)



来源:https://stackoverflow.com/questions/49816855/is-lock-free-returned-false-after-upgrading-to-macports-gcc-7-3

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!