adalava added a comment. In D71600#1816160 <https://reviews.llvm.org/D71600#1816160>, @MaskRay wrote:
> I am still confused why you need the special rule for `__atomic_is_lock_free` > (GCC/clang) and `__c11_atomic_is_lock_free` (clang). > > https://github.com/gcc-mirror/gcc/blob/master/gcc/builtins.c#L7300-L7314 GCC > `__atomic_is_lock_free` expands to either 1 or a library call to > `__atomic_is_lock_free`, never 0. How did FreeBSD get around libatomic when > it was still using GCC? In clang, We can probably extend the semantics of > `__c11_atomic_is_lock_free` and use > `clang::TargetInfo::getMaxAtomicPromoteWidth`, but I'll make more research in > this area. > > Can you be elaborate how do > `__atomic_is_lock_free`/`__c11_atomic_is_lock_free` pull in libatomic.{a,so} > dependency on FreeBSD powerpc? On FreeBSD 11.x/12.x (GCC4), libatomic can be installed by user through "gcc9" ports package. The library is not shipped with the base system and it's not required to compile the base system (world + kernel) since nothing depends on 64 bit atomics an external call so `__atomic_is_lock_free` is never made. The problem appeared when I switched to clang in a new ISO, this added an undesired external libatomic dependency to build FreeBSD base sources (world): clang was emitting a call to external `__atomic_is_lock_free` implementation when building clang itself from base sources. (user would need to install gcc9 to be able to build FreeBSD base source using clang, it's not acceptable. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71600/new/ https://reviews.llvm.org/D71600 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
