Clang: error: unknown argument: '-fswift-async-fp=always'

Hi,
After an update-checkout, trying to re-build the the compiler for Xcode with SKIP_XCODE_VERSION_CHECK=1 ./swift/utils/build-script --xcode --release-debuginfo --debug-swift --skip-build-benchmarks --swift-darwin-supported-archs "$(uname -m)" --sccache --skip-ios --skip-tvos --skip-watchos and clang: **error:** unknown argument: '-fswift-async-fp=always' come up, the problem seems that for Xcode builds it is using the pre-built version that ships with Xcode (using 12.5.1), ninja build seems fine since it uses the one built from source. We have a similar problem before, here https://bugs.swift.org/browse/SR-14714 but with a different flag.

So my question is if there is a simple way to get around this? Make Xcode builds use the from source built clang or it is better to download and try a beta version of Xcode to fix this? Or maybe another approach?
Thanks in advance!

Best Regards,
Luciano Almeida

To me, it seems like a bug that the --xcode build doesn't use the locally built Clang. Different build systems should still be using the same overall compilation commands, otherwise this issue will keep coming up from time to time because of the skew between apple/llvm-project and what is available in the latest Xcode release.

(cc @Michael_Gottesman)

1 Like

The required version of Xcode is currently 13 beta 4 or newer, according to the information on ci.swift.org and GettingStarted.md.

I think the build-script should only contain that version number, so we don't need to use SKIP_XCODE_VERSION_CHECK=1 for newer versions (e.g. the release candidate).

The only issue is that Xcode build numbers may not be monotonic, for beta and release versions.

1 Like

There is a broader issue here, which is that till now it was possible to build the Swift stdlib with a stock upstream OSS clang on all platforms. However, the pull that added this flag would now require that only the Swift-forked clang be used to build the stdlib, eg on my Android CI which uses the NDK clang and just broke because of this change.

Maybe we can detect whether the Swift-forked clang is being used and only pass flags like this to it?

Unless the NDK clang is tracking LLVM's main fairly closely, I expect you'll run into problems with async/await support, because Swift is relying on custom async calling conventions implemented in LLVM within the last few months.

Now, this particular change that adds the -fswift-async-fp=always flag is only specifically relevant to Darwin, because the default behavior on all other platforms is good enough. We should go ahead and not pass the flag for non-Darwin platforms.

That doesn't necessarily help @LucianoPAlmeida's Xcode build. We can disable the flag there, and I think only the back-deployed concurrency stuff under development will break, so perhaps that is enough.

The danger here is that these flags may have an effect on code generation, and if the C++ bits of the Swift runtime are built without them, the resulting runtime could be broken.

Doug

1 Like

Unless the NDK clang is tracking LLVM's main fairly closely, I expect you'll run into problems with async/await support

It doesn't track it that closely, as the latest NDK 23 from last month appears to use a clang commit from January. I built the Sept. 2 trunk source snapshot of the Swift toolchain with the upstream clang 12.0.1 on my Android phone, and all the compiler validation suite Concurrency tests passed on Android 11 AArch64 so it hasn't been a problem yet.

We should go ahead and not pass the flag for non-Darwin platforms.

OK, I will submit a pull for that.

The danger here is that these flags may have an effect on code generation, and if the C++ bits of the Swift runtime are built without them, the resulting runtime could be broken.

Good to know. Is the plan to let the Swift-forked clang permanently diverge from upstream clang or get these clang differences upstreamed eventually, as @DaveZ has been monitoring for?

The plan is to get it all upstream. This flag is already upstream (it went there first), but there’s always lag until the next release for a given platform/vendor.

Oh, I see you upstreamed it on Thursday. Looking at your patch, it appears removing that flag from the non-Darwin stdlib build will change it on non-Darwin from never to the default of always, but it had the same behavior before you added the flag, so I guess always should be fine too.

I'll submit the pull in a little bit, thanks for the info.

I built the Sept. 2 trunk source snapshot of the Swift toolchain with the upstream clang 12.0.1 on my Android phone, and all the compiler validation suite Concurrency tests passed on Android 11 AArch64 so it hasn't been a problem yet.

I looked into this a bit more, and while a few C++ files in the stdlib are built with the host clang, ie upstream clang 12.0.1 in the Termux app, most are built with the Swift-forked clang that should have the changes you refer to, so that explains why that problem hasn't hit. My Android CI cross-compiles from linux with the NDK clang instead, so maybe the problem exists there but the Concurrency library is probably not used or exercised much by those Swift packages tested there yet.

Thanks for the response @Douglas_Gregor,
I think for me disabling the flag for the Xcode build locally would be just enough, will not affect the workflow I currently have. But as @typesanitizer mentioned this is a recurrent issue that occurs whenever a new flag is added on clang to support some new swift fix/feature for example https://bugs.swift.org/browse/SR-14714, so for that problem maybe the solution would be make the Xcode build use the locally built from source clang the same way ninja builds do today.
I think it would be just fine, but I don't have much understanding about side effects such change would have ... do you think is a viable option?

JIRA ticket for this issue: https://bugs.swift.org/browse/SR-15216

Hey yall, I filed that jira ticket yesterday while somehow missing this discussion here.

Last night, I ended up deleting all of my previous Xcode versions and downloaded the 13.4 beta and accompanying command line tools to see if that would fix this issue. I started the build again without the skip xcode version check var, but I woke up to a failed build again with the same error messages this morning.

I've submitted a pull that elides the flag if not found on non-Darwin and should error on Darwin for the Xcode build, based on a suggestion by @DaveZ.

1 Like

I've also run into this error now. I am using Xcode 13 beta 4.

1 Like

@RyanK @amritpan It is still an issue for all Xcode builds right now, there are more details on @Buttaface's PR here Check if the C++ compiler used to build the Concurrency library has the -fswift-async-fp flag by buttaface · Pull Request #39368 · apple/swift · GitHub but we still don't have a fix, and at least as far as I know we don't have a work around it as well ... so Xcode builds are not working right now.
Does someone found a workaround for building it?

I think just to unlock the build maybe try locally revert the PR that introduced the flag Add flag -swift-async-framepointer=auto,never,always to control swift extended frame information emission by aschwaighofer · Pull Request #39245 · apple/swift · GitHub with git revert cffc1b212196a52d45aabb007b5af156e0dfb82f -m 2 but note I didn't test this so maybe it doesn't work and also not sure is recommended :sweat_smile:

1 Like

Thanks! I've gotten a working build by going back to the 5.4 release with git checkout swift-5.4-DEVELOPMENT-SNAPSHOT-2021-03-19-a && utils/update-checkout --tag swift-5.4-DEVELOPMENT-SNAPSHOT-2021-03-19-a. This works for the meantime :slight_smile:

1 Like

That is fairly old: you should just checkout swift-DEVELOPMENT-SNAPSHOT-2021-09-14-a, which was the last tag before the commit adding this flag was merged.

I've submitted another pull to work around this issue on macOS, you could try that out on a more recent tag too.

1 Like
Terms of Service

Privacy Policy

Cookie Policy