jfb added a comment. Just a guess, but maybe the return type was intended to match what a C implementation does with `atomic_is_lock_free` as a macro: https://en.cppreference.com/w/c/atomic/atomic_is_lock_free If so, maybe the expectation is that a macro could define `atomic_is_lock_free` using `__atomic_is_lock_free`, and expect something compatible with `_Bool`? In C++ we use `__atomic_is_lock_free ` in inlined functions, so `int` to `bool` is fine.
In other words, the builtin can return `int` just fine, but we should consider how we expect library implementations to use them before changing the return type. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79504/new/ https://reviews.llvm.org/D79504 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
