The IS_LOCK_FREE_* macros in atomic.c were using the __c11_atomic_is_lock_free builtin. Those specific builtin calls would typically be lowered to compile-time constants (probably for all of the scenarios where compiler-rt was being used and providing atomic builtins). In some cases, though, the builtin can be lowered to a call to the runtime function __atomic_is_lock_free. An example is when targeting RISC-V rv32imac and it calls __c11_atomic_is_lock_free(8) by using the IS_LOCK_FREE_8 macro. Yet, atomic.c doesn't provide an implementation of __atomic_is_lock_free. In those scenarios you aren't able to link your program. To address this issue, this patch changes the macros to be implemented in terms of the __atomic_always_lock_free builtin, which is always lowered to a compile-time constant.
An alternative approach would be to implement the run-time function __atomic_is_lock_free, but right now that would only add run-time overhead. atomic.c implements the builtin runtime functions in terms of other atomic builtins, but the only relevant builtin here is __atomic_always_lock_free, so you might as well just use that builtin in the first place. If compiler-rt started to deviate from the current implementation approach and providing architecture-specific logic it's theoretically possible that a more fine-grained implementation of __atomic_is_lock_free could allow covering additional cases with lock-free implementations. If that ever comes to pass, we can revisit the implementation of the macros changed by this patch.