On targets that have limited atomic support, e.g. ones that define ATOMIC_*_LOCK_FREE to '1' ("sometimes lock free"), we would end up referencing yet-undefined __libcpp_{,un}signed_lock_free. This commit adds a guard to prevent these references for such targets.
Details
- Reviewers
ldionne - Group Reviewers
Restricted Project - Commits
- rGd5ab243c6f79: Omit atomic_{,un}signed_lock_free if unsupported
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This kooks sensible to me. I assume this is based on compiling for a funky target and it not working (and this is the fix).
Is this configuration (target, etc.) something we could run in our CI? Like is it possible to run this configuration in a Docker image or something? It would be awesome to have tests for it.
This configuration that encountered the failure is an ARMv6 baremetal target -- not sure if we can run it in the CI. @efriedma do you happen to know if all the bits required to reproduce this configuration that hit the issue downstream are present upstream? I suspect so.
FWIW I would really love to have a baremetal target tested in the CI. I'd be willing to put in some work on this if you can help out, since I think there would be wide benefits for various types of users.
The way to reproduce this is to build libc++ using a triple that doesn't have any lock-free atomic types. For example, arm-none-gnueabi, or armv6m-none-gnueabi, or riscv32-unknown-elf. As far as I know, all commonly used non-baremetal targets have lock-free atomics, so this is only an issue for baremetal. (e.g. riscv32-linux assumes atomics, and arm-linux uses kernel emulation of atomics.)
Internally, we use a proprietary C library, so I don't think we can really help with setting up a public buildbot.