-
Notifications
You must be signed in to change notification settings - Fork 10.5k
5.5 fix weak extended frame pointer flags #40044
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
5.5 fix weak extended frame pointer flags #40044
Conversation
The weakly-imported symbol was getting optimized out, then put back in as a strongly-imported symbol. This is no good. The symbol is a declaration though, so it can't be "used" directly. Instead, we assign it to another global and "use" it. That avoids the optimizations and should be fine. Even if that symbol is a nullptr because it doesn't exist, we are taking the pointer to it, which should be fine for all situations.
Make the little variable LinkOnceODRLinkage so that it doesn't take up as much space.
0865ced
to
ffcbdc6
Compare
@swift-ci please test |
Build failed |
@swift-ci please test macOS |
Build failed |
@swift-ci please test macOS |
Build failed |
@swift-ci please test macOS |
Build failed |
@swift-ci please test macOS platform |
Build failed |
@swift-ci please test macOS |
Build failed |
MacOS failure is unrelated:
|
This PR should fix the issue: |
@swift-ci please test macOS |
Thank you! |
Cherry-pick of: #40035
The weakly-imported symbol was getting optimized out, then put back in
as a strongly-imported symbol. This is no good. The symbol is a
declaration though, so it can't be "used" directly. Instead, we assign
it to another global and "use" it. That avoids the optimizations and
should be fine. Even if that symbol is a nullptr because it doesn't
exist, we are taking the pointer to it, which should be fine for all
situations.
Fixes rdar://84877644.