Link the concurrency runtime against libatomic on Linux #38501
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We mostly get away without this because we're fairly disciplined about using constant memory orderings, and apparently that's usually good enough to get inline accesses and avoid needing to link atomic. However, we have a few places with the task status atomic that use a non-constant load ordering with load and compare_exchange_weak, and my recent change to make that atomic a double-word was apparently sufficient on some (but not all) Linux distributions to get the compiler to call the runtime function. Regardless, we shouldn't be playing around in the margins here: Linux requires us to link libatomic, so we should.
|
@swift-ci Please test |
finagolfin
reviewed
Jul 20, 2021
| # Frustratingly, in many cases this isn't necessary because the | ||
| # sequence is inlined, but we have some code that's just subtle | ||
| # enough to turn into runtime calls. | ||
| if(SWIFT_HOST_VARIANT STREQUAL "Linux") |
There was a problem hiding this comment.
Do you mind adding Android here? It is the only platform currently distributing an up-to-date Swift 5.4 toolchain for a 32-bit platform, armv7.
There was a problem hiding this comment.
@rjmccall @buttaface is it possible to make this change in different PR? I would like to merge this change to unblock nightly toolchain.
There was a problem hiding this comment.
Sure, no problem. I can always add it later if you need this patch right away.
|
Huh, thanks for the explanation in the opening comment, good to know! |
ktoso
approved these changes
Jul 20, 2021
|
We will need this change on release/5.5 branch too, it's also failing there. |
This was referenced Jul 20, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We mostly get away without this because we're fairly disciplined about using constant memory orderings, and apparently that's usually good enough to get inline accesses and avoid needing to link atomic. However, we have a few places with the task status atomic that use a non-constant load ordering with
loadandcompare_exchange_weak, and my recent change to make that atomic a double-word was apparently sufficient on some (but not all) Linux distributions to get the compiler to call the runtime function. Regardless, we shouldn't be playing around in the margins here: Linux requires us to link libatomic, so we should.