This is an archive of the discontinued LLVM Phabricator instance.

Omit atomic_{,un}signed_lock_free if unsupported
ClosedPublic

Authored by bcain on Jan 27 2022, 9:20 AM.

Details

Reviewers
ldionne
Group Reviewers
Restricted Project
Commits
rGd5ab243c6f79: Omit atomic_{,un}signed_lock_free if unsupported
Summary
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.

Diff Detail

Event Timeline

bcain requested review of this revision.Jan 27 2022, 9:20 AM
bcain created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptJan 27 2022, 9:20 AM
Herald added 1 blocking reviewer(s): Restricted Project. · View Herald Transcript
ldionne accepted this revision.Jan 27 2022, 1:55 PM

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 revision is now accepted and ready to land.Jan 27 2022, 1:55 PM
miyuki added a subscriber: miyuki.Jan 27 2022, 1:58 PM
bcain added a comment.Jan 27 2022, 2:27 PM

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.

This revision was automatically updated to reflect the committed changes.

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.