You have patch.patch in the diff above. You should drop that.

s/integrates/integrated in the title, but otherwise this looks good.

Craig, can you confirm that this is acceptable? I don't think there are any chips with SSE4.2 but without cx16, so this just seemed like an oversight. It might be a good idea to really audit the list of possible CPU features for other missing inclusions. Another idea would be to set a baseline minimum CPU for Android, which would cut down on having to specify so many features separately.

FYI, https://reviews.llvm.org/D56571 is the review where this was accepted.

Everything looks great. Thanks for adding these improvements. While it's probably safe to commit this, perhaps you should give it 24 hours in case some of the other clang-tidy folks have different style or testing concerns.

Thanks for picking this up and finishing it.

The revert is fine with me, although I still would like Ryan to follow up on verifying that the suggested fix for Bionic will indeed work for all cases. I think it is fine for you to merge now to unbreak things for everyone else though. Thanks for working through the problem.

This LGTM if Ryan is happy with it. Thanks for taking care of getting a workaround implemented until this can be fixed.

I had just a few small suggestions to make things more consistent. Feel free to ignore my fallthrough comment, but I feel like -Wimplicit-fallthrough has been quite valuable in Android.

I added Peter and Oliver since they might have some suggestions here too.

Thanks for taking a look at this.

Thanks for finding this. Note that this is the exact code in comparesf2.c.

In D60577#1463469, @smeenai wrote:

I have zero context on this change specifically, but "we should prefer functions in a private namespace" seems to be the exact opposite of the advice in https://llvm.org/docs/CodingStandards.html#static

Thank you for fixing this quickly!

In addition to -fno-everything, don't forget about -fnothing and -fno-nothing, which seem like they would also be nice to have.

@jmorse can I get your approval on this CL before we submit it? Thanks.

https://reviews.llvm.org/D59807 has the fix for the nondeterminism. Thanks for the hints about the reverse iteration order. That helps make it more likely to fail deterministically, but it still runs a small chance of "passing" if the fix isn't there.

Switching it to a MapVector makes it deterministic. I was just struggling late last night to try to reduce the .ll file down to something worth checking in! If you want to take over to minimize the test case, that would be much appreciated. Let me know so I can continue doing that if needed. Thanks.

This patch appears to generate non-reproducible builds in some cases. I can craft a more minimal test case, but the following link (https://godbolt.org/z/sWucUZ) is what I have been using. If I run Clang multiple times, the output eventually swaps the order of some undef DEBUG_VALUE's. I am just passing "-O1 -g" with that .ii file. It isn't obvious to me yet what is causing this to be unordered/non-deterministic.

Dan, this seems pretty important for the NDK. If you submit this, would you want it cherry-picked ASAP?

I asked Chris to comment here about libunwindstack. Hopefully we can get the problem fixed, but I think this workaround might be necessary for code running on older devices in any case (i.e. NDK apps).

Very cool, thank you for coming up with a great way to improve this case.

Would it be reasonable to have a test for this with perhaps an invalid GCC installation? There is some mock GCC/sysroot testing in https://github.com/llvm/llvm-project/blob/master/clang/test/Driver/android-gcc-toolchain.c and https://github.com/llvm/llvm-project/blob/master/clang/test/Driver/android-ndk-standalone.cpp. I am not sure that it will be easy to trip this same bug that way, but I think it is possible.

LGTM for removing the broken Android builders.

In D36806#1385936, @lhames wrote:

Looks like this was LGTM'd but never applied. Stephen -- do you have commit access?

Sorry about the delay.

Craig, does this look ok now?

In D55029#1312167, @ruiu wrote:

I wouldn't rush to submit this now, given that this issue is not new at all. Maybe we can just wait for Peter's response?

Thanks Zhizhou! I'm curious about Peter's answer to the 64KiB default as well, but I think we should move forward with getting this patch submitted.

I just wanted to follow up here.

Yabin did some of the work to bring TSan to Android. Perhaps he knows whether this is has significant use. Considering that it is meant as a debugging aide, I would actually be comfortable with moving it. You are also correct that we never officially marked it as a feature of the NDK (or platform). That is something we want to do though.

LGTM, but please wait for dberris approval.

Please remove the reference to b/X in the commit message. LLVM doesn't allow internal bug numbers, and you described the issue well enough without it.

This LGTM, but we should wait to hear from Kristof before submitting.

Really cool! Thanks for making everything easier to use out-of-the-box.

+enh and danalbert - in case they have any other concerns about this (Ryan's already on the review). From my perspective, everything here makes sense for resolving this issue.

Thanks @dblaikie for the quick fixup. I must have accidentally dropped the '!', because I did run check-all to test the change.

In D52191#1238628, @dblaikie wrote:

Sure, looks good. Though my other/vague concern is why does this case error about fomit-frame-pointer having no effect, but other things (like using -fomit-frame-pointer on a target that requires frame pointers) that ignore -fomit-frame-pointer don't? Weird. But it probably makes sense somehow.

+Ryan in case there is anything here that could affect Bionic loading from these pages.