The patch tested on NDK r26 bulding simple Function Multi Versioning project and running on Android API 25,29,30,33 - works fine.

Use weak "memfd_create" to check for API 30+, split and rename init cpu features functions ( __init_cpu_features, __init_cpu_features_resolver, __init_cpu_features_constructor )

Offtopic: Outlining atomics seems to be very CPU specific thing. In my experience LSE were ~= old exclusive semantics. So adding extra call + extra bit check (too bad IFUNCs are not used :)) each time it would be executed seems to be quite an extra load (for CPU, TLB, dcache..), so I'm not sure that outline atomics is a win-win thing (at least on some of the CPUs). This is absolutely not a case for this patch anyway, just some of my thoughts, I would be glad to hear other opinions :)

Outline atomics overhead is mostly negligible. "Various members in the Arm ecosystem have measured the performance impact of this indirection on a diverse set of systems and we were happy to find out that it was minimal compared to the benefit of using the LSE instructions for better scalability at large core counts." https://community.arm.com/arm-community-blogs/b/tools-software-ides-blog/posts/making-the-most-of-the-arm-architecture-in-gcc-10
For IFUNCs Function Multi Versioning https://github.com/ARM-software/acle/blob/main/main/acle.md#function-multi-versioning lse feature can be used.

I understand that you could disable it with extra option and that for now it would be different with gcc, but it looks debatable to me that such a behaviour in gcc is correct and expected, maybe someone need to change it there too. (Please keep in mind that I might be wrong with my position and during discussion please consider this patch as NFC so we could discuss here am I right or not :)). My point is that the gcc is not a golden standard in this questions too and in my mind such a behaviour (disabling extra dependencies in freestanding mode without passing extra flags) would be expected the very same way the -fno-builtint get's auto implied with -ffreestanding flag passed.

Outline atomics are dependent on runtime library availability ( libgcc or compler-rt ). If there are no proper library available they will be disabled. So if in freestanding mode compiler is not dependent on runtime library you can remove it and get rid of outline atomics calls automatically.
Having runtime library in freestanding mode you can disable outline atomics specifying -mno-outline-atomics option. But disabling them just by -ffreestanding option will create divergence with GCC behaviour, which has outline atomics not disabled in this case.

From what i understand in freestanding environment runtime library is not used and clang driver can detect this situation and set outline atomics off by default ( see clang/lib/Driver/ToolChains/Linux.cpp Linux::IsAArch64OutlineAtomicsDefault -> GetRuntimeLibType )

In D159174#4635886, @BeMg wrote:

I'm working on RISC-V FMV support, and we found the large set of extension features is hard to maintain the priority that doesn't collision at all.

On AArch64 for FMV we are using target_version attribute and AppendTargetVersionMangling with llvm::stable_sort

Friendly ping, are there any questions remained to proceed with target-independent __builtin_cpu_supports ?

In D152914#4497599, @nemanjai wrote:

I took a quick look at your patch. I think it would be preferable to make the builtins target-independent rather than implementing the builtin by the same name for multiple targets. Although I think it is very useful to support a plus-separated list for __builtin_cpu_supports(), I think that's probably something for a subsequent patch. We would need to figure out code generation for that - perhaps that part will have to be completely target specific.

I fully agree with you to make __builtin_cpu_supports() target-independent ( and I will update my patch on top of yours ). If plus-separated format is not supported by all targets then I would suggest to make SemaBuiltinCpuSupports target-dependent - it allows to implement plus-separated format on AArch64 keeping __builtin_cpu_supports() target-independent.

Thank you for the patch, it comes in the right time - we are also working on AArch64 __builtin_cpu_supports, and I was thinking how to make it more general.
I uploaded our RFC version for review https://reviews.llvm.org/D153153

It would be great to have in __builtin_cpu_supports argument string of plus-separated features. Just SemaBuiltinCpuSupports need to handle this.

LGTM, thanks!

I think the order should instead be:

1. include system headers that potentially defined HWCAP_xxx
2. block with #ifndef HWCAP_xxx ... #define HWCAP_xxx ...
3. block with inline functions actually using HWCAP_xxx

Absolutely correct. I think system headers includes

#if defined(__has_include)
#if __has_include(<sys/auxv.h>)
#include <sys/auxv.h>
#if __has_include(<asm/hwcap.h>)
#include <asm/hwcap.h>

Rebasing and addressing comments.

In D127812#4085171, @tmatheson wrote:

This patch has made it considerably harder to understand what is going on in the TargetParser. If you get a chance, please could you add some clarifying comments and tidy-ups. I appreciate that a lot of this is following the lead of the pre-existing TargetParser code, but lets try to improve it as we go.

I fully agree, thank you for valuable comments! Let me address them in separate patch.

Sorry, commit rG5474d7d93271 is not related to this, I put wrong differential revision link

LGTM, thanks for fixing this!

In D127812#4031994, @smeenai wrote:

You're right that it conceptually makes sense for this to be in cpu_model.c though. An alternative would be providing an option for compiler-rt to be built without the multiversioning support, e.g. if it's built with -mno-fmv itself. Does that seem reasonable?

Sounds good to me, please look into the patch adding such cmake option https://reviews.llvm.org/D141199
Using cmake -DCOMPILER_RT_DISABLE_AARCH64_FMV=On will exclude Aarch64 multiversioning support from compiler-rt build.

In D127812#4031313, @smeenai wrote:

We can use -mno-fmv to avoid that dependency, right? We're interested in using that for our own code (where we don't make use of function multi-versioning), and want to prevent the compiler-rt support from being pulled in from the archive unnecessarily. It'd still be available for users who needed it.

Right, you will need to explicitly provide '-mno-fmv` then. Currently __aarch64_cpu_features cpu_model.c stuff located in bultins (libclang_rt.builtins-aarch64.a). Did I understand you correctly that your apps linked agains libclang_rt.builtins-aarch64.a and if we move function multiversioning part to new library, lets say libclang_rt.cpu_features-aarch64.a, that will resolve your concern ? As a sidenote, builtins/cpu_model.c contains X86 CPU features used in function multiversioning on that target as well.

In D127812#4030881, @smeenai wrote:

We're not actually using multi-versioning anywhere, but we're still paying the size cost for it as a result. Would we consider moving the newly added functions into their own file (or perhaps moving the outlined atomics functions into a different file), so that you can use outlined atomics without also paying the size cost of function multiversioning if you don't need it?

Function multiversioning expects compiler-rt has __aarch64_cpu_features, it will be broken if compiler-rt miss that ( clang/lib/Driver/ToolChains/Clang.cpp:7231 ). I believe function multiversioning will be used in Android as outline atomics already did.

I also had a couple of general questions, since I think I'm missing something obvious:

• How come we need both init_cpu_features and init_cpu_features_resolver? It seems like we're codegenning calls to the latter where needed, so I'm not sure what the former is adding on top.
• From what I can see, we're codegenning calls to init_cpu_features_resolver without any arguments, but the actual definition of that function has two arguments. How does that work?

hwcaps are ABI specified arguments of ifunc resolver. The constructor init_cpu_features calls getauxval to initialize hwcaps and then pass them explicitly to init_cpu_features_resolver. If resolver called before constructor we get init_cpu_features_resolver hwcap and hwcap2 as arguments from dynamic loader.

In D131058#3973885, @dmgreen wrote:

Rebase. This requires some dependencies between target features, which is being added in D127812. I would like to get this in sooner rather than later though, to not get too close to a release. There is a simple versions for sve features in this patch. @ilinpv @sdesmalen what do you think?

FMV patch with target feautures dependencies relanded fe5cf480ee5a

In D127812#4018490, @mceier wrote:

Checked the changes I'm suggesting and they fix the standalone build.

Thanks! Fix committed 2184fcf17ee00a939b3bde98a28ef586c67d6b1a

Many thanks @hctim for investigation! I refactored Strings and StringsBuffer not to capture dangling references - use-of-uninitialized-value errors were fixed. I would reland this patch if you don't mind.

In D127812#4012283, @hctim wrote:

I'm not sure "MSan didn't handle correctly SmallVector" is the case. Given your diagnosis of 3-elements-vs-2, I'm guessing the root cause is that clang/lib/Sema/SemaDecl.cpp:11369 is wrong:

!std::equal(CurClones->featuresStrs_begin(),
            CurClones->featuresStrs_end(),
            NewClones->featuresStrs_begin()))) {

This construction of std::equal is very error-prone, as if NewClones.size() < CurClones.size(), then this invariable leads to buffer-overflow. I'm wondering if that's the underlying cause, it would seem entirely possible that expanding the in-place elements are always "initialized" from MSan's perspective and so the current code has a false-negative, and your new code made it so that the vector is now heap-based, which is revealing the underlying issue. Maybe worth trying one more thing and adding an assert(CurClones->size() <= NewClones->size()); to double check?

I don't think std::equal is underlying cause here. We have featuresStrs_size() comparison before calling it:

I've managed to reproduce "MemorySanitizer: use-of-uninitialized-value" error locally, thank you @hctim for help!
If I understand it right, it seems MSan didn't handle correctly SmallVector - a variable-sized array with some number of elements in-place and heap allocation for additional elements if needed:

In D127812#4010993, @hctim wrote:

Hmm, not exactly sure what's going on with the could NOT find Threads there. A quick googling seems to point to pthreads.so not being in the right places, but I don't think the buildbot does anything special. Do your regular builds with -DLLVM_ENABLE_PROJECTS="compiler_rt;clang;lld" work?

When you say that it looks fine locally, is that from your own checkout but using -DLLVM_USE_SANITIZER=Memory? First thing to check is that you do end up with MSan in the test (in particular the clang binary that's being produced), which you can do by nm bin/clang-16 | grep __msan_init.

Regular builds works fine for me, pthreads located here "/lib/x86_64-linux-gnu/libpthread.so" "/usr/lib/x86_64-linux-gnu/libpthread.so". Enabling "-DLLVM_USE_SANITIZER=Memory" resulted in many "WARNING: MemorySanitizer: use-of-uninitialized-value" on tblgen like:

In D127812#4009577, @hctim wrote:

In D127812#4009447, @hctim wrote:

Hi, this looks like a candidate for breaking the MSan bot: https://lab.llvm.org/buildbot/#/builders/5/builds/30139

Still looking into it and bisecting, will let you know when I have more info. To reproduce the bots, the best way (because MSan setup is tricky because it requires an instrumented libcxx) is to use the scripts from https://github.com/google/sanitizers/wiki/SanitizerBotReproduceBuild (buildbot_fast.sh is the right one).

Yeah, unfortunately I did track this failure down to this commit and reverted it upstream. If you need help figuring it out, please let me know. You may find that adding -fsanitize-memory-track-origins=2 useful to add to the buildscript as well (which can be done by changing check_stage2_msan to check_stage2_msan_track_origins in buildbot_fast.sh.

In D127812#4009014, @paulkirth wrote:

Hi, thanks for the fix. that unblocked our builder. Unfortunately, we still see some errors in tests.

FAIL: Clang :: Driver/aarch64-features.c (7460 of 16622)
******************** TEST 'Clang :: Driver/aarch64-features.c' FAILED ********************
Script:
--
: 'RUN: at line 1';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target aarch64-none-linux-gnu -### /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c -fsyntax-only 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 2';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target arm64-none-linux-gnu -### /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c -fsyntax-only 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 10';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target aarch64-linux-android -rtlib=compiler-rt  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -check-prefix=CHECK-FMV /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 13';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target aarch64-linux-android -rtlib=compiler-rt -mno-fmv  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -check-prefix=CHECK-FMV-OFF /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 16';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target aarch64-linux-gnu  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -check-prefix=CHECK-FMV-OFF /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 19';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target arm64-unknown-linux -rtlib=libgcc  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -check-prefix=CHECK-FMV-OFF /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 26';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target aarch64-linux-android -rtlib=compiler-rt  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -check-prefix=CHECK-OUTLINE-ATOMICS-ON /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 29';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target aarch64-linux-gnu -rtlib=compiler-rt  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -check-prefix=CHECK-OUTLINE-ATOMICS-ON /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 32';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target arm64-unknown-linux -rtlib=compiler-rt  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -check-prefix=CHECK-OUTLINE-ATOMICS-ON /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 35';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target aarch64--none-eabi -rtlib=compiler-rt  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -check-prefix=CHECK-OUTLINE-ATOMICS-OFF /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 38';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target aarch64-apple-darwin -rtlib=compiler-rt  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -check-prefix=CHECK-OUTLINE-ATOMICS-OFF /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 41';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target aarch64-windows-gnu -rtlib=compiler-rt  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -check-prefix=CHECK-OUTLINE-ATOMICS-OFF /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 44';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target aarch64-unknown-openbsd -rtlib=compiler-rt  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -check-prefix=CHECK-OUTLINE-ATOMICS-OFF /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 47';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target aarch64-linux-gnu -rtlib=libgcc  --gcc-toolchain=/b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/Inputs/aarch64-linux-gnu-tree/gcc-10  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -check-prefix=CHECK-OUTLINE-ATOMICS-ON /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 51';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target aarch64-linux-gnu -rtlib=libgcc  --gcc-toolchain=/b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/Inputs/aarch64-linux-gnu-tree/gcc-7.5.0  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -check-prefix=CHECK-OUTLINE-ATOMICS-OFF /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 55';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target aarch64-linux-gnu -rtlib=libgcc  --gcc-toolchain=/b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/Inputs/aarch64-linux-gnu-tree/gcc-9.3.1  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -check-prefix=CHECK-OUTLINE-ATOMICS-ON /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 59';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target aarch64-linux-gnu -rtlib=libgcc  --gcc-toolchain=/b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/Inputs/aarch64-linux-gnu-tree/gcc-9.3.0  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -check-prefix=CHECK-OUTLINE-ATOMICS-OFF /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 63';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target arm64-linux -rtlib=compiler-rt -mno-outline-atomics  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck  -check-prefixes=CHECK-OUTLINE-ATOMICS-OFF,CHECK-NO-OUTLINE-ATOMICS /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 67';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target aarch64-linux-gnu -rtlib=libgcc -mno-outline-atomics  --gcc-toolchain=/b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/Inputs/aarch64-linux-gnu-tree/gcc-10  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck  -check-prefixes=CHECK-OUTLINE-ATOMICS-OFF,CHECK-NO-OUTLINE-ATOMICS /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 72';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target aarch64-apple-darwin -rtlib=compiler-rt -moutline-atomics  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -check-prefix=CHECK-OUTLINE-ATOMICS-ON /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
: 'RUN: at line 75';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -target aarch64-windows-gnu -rtlib=libgcc -moutline-atomics  --gcc-toolchain=/b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/Inputs/aarch64-linux-gnu-tree/gcc-7.5.0  -### -c /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c 2>&1 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -check-prefix=CHECK-OUTLINE-ATOMICS-ON /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c
--
Exit Code: 1

Command Output (stderr):
--
/b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c:22:19: error: CHECK-FMV-OFF: expected string not found in input
// CHECK-FMV-OFF: "-target-feature" "-fmv"
                  ^
<stdin>:1:1: note: scanning from here
Fuchsia clang version 16.0.0 (https://llvm.googlesource.com/llvm-project 9b2fecec406d6a6bcda9fbb9251db2ae202c7400)
^
<stdin>:6:461: note: possible intended match here
 "/b/s/w/ir/x/w/staging/llvm_build/bin/clang-16" "-cc1" "-triple" "aarch64-unknown-linux-gnu" "-emit-obj" "-mrelax-all" "--mrelax-relocations" "-disable-free" "-clear-ast-before-backend" "-main-file-name" "aarch64-features.c" "-mrelocation-model" "pic" "-pic-level" "2" "-pic-is-pie" "-mframe-pointer=non-leaf" "-fmath-errno" "-ffp-contract=on" "-fno-rounding-math" "-mconstructor-aliases" "-funwind-tables=2" "-target-cpu" "generic" "-target-feature" "+neon" "-target-feature" "+v8a" "-target-abi" "aapcs" "-mllvm" "-treat-scalable-fixed-error-as-warning" "-debugger-tuning=gdb" "-fcoverage-compilation-dir=/b/s/w/ir/x/w/staging/llvm_build/tools/clang/test/Driver" "-resource-dir" "/b/s/w/ir/x/w/staging/llvm_build/lib/clang/16" "-internal-isystem" "/b/s/w/ir/x/w/staging/llvm_build/lib/clang/16/include" "-internal-isystem" "/usr/local/include" "-internal-externc-isystem" "/include" "-internal-externc-isystem" "/usr/include" "-fdebug-compilation-dir=/b/s/w/ir/x/w/staging/llvm_build/tools/clang/test/Driver" "-ferror-limit" "19" "-fno-signed-char" "-fgnuc-version=4.2.1" "-target-feature" "+outline-atomics" "-faddrsig" "-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-o" "aarch64-features.o" "-x" "c" "/b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c"
                                                                                                                                                                                                                                                                                                                                                                                                                                                                            ^

Input file: <stdin>
Check file: /b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c

-dump-input=help explains the following input dump.

Input was:
<<<<<<
            1: Fuchsia clang version 16.0.0 (https://llvm.googlesource.com/llvm-project 9b2fecec406d6a6bcda9fbb9251db2ae202c7400) 
check:22'0     X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
            2: Target: aarch64-unknown-linux-gnu 
check:22'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            3: Thread model: posix 
check:22'0     ~~~~~~~~~~~~~~~~~~~~
            4: InstalledDir: /b/s/w/ir/x/w/staging/llvm_build/bin 
check:22'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            5:  (in-process) 
check:22'0     ~~~~~~~~~~~~~~
            6:  "/b/s/w/ir/x/w/staging/llvm_build/bin/clang-16" "-cc1" "-triple" "aarch64-unknown-linux-gnu" "-emit-obj" "-mrelax-all" "--mrelax-relocations" "-disable-free" "-clear-ast-before-backend" "-main-file-name" "aarch64-features.c" "-mrelocation-model" "pic" "-pic-level" "2" "-pic-is-pie" "-mframe-pointer=non-leaf" "-fmath-errno" "-ffp-contract=on" "-fno-rounding-math" "-mconstructor-aliases" "-funwind-tables=2" "-target-cpu" "generic" "-target-feature" "+neon" "-target-feature" "+v8a" "-target-abi" "aapcs" "-mllvm" "-treat-scalable-fixed-error-as-warning" "-debugger-tuning=gdb" "-fcoverage-compilation-dir=/b/s/w/ir/x/w/staging/llvm_build/tools/clang/test/Driver" "-resource-dir" "/b/s/w/ir/x/w/staging/llvm_build/lib/clang/16" "-internal-isystem" "/b/s/w/ir/x/w/staging/llvm_build/lib/clang/16/include" "-internal-isystem" "/usr/local/include" "-internal-externc-isystem" "/include" "-internal-externc-isystem" "/usr/include" "-fdebug-compilation-dir=/b/s/w/ir/x/w/staging/llvm_build/tools/clang/test/Driver" "-ferror-limit" "19" "-fno-signed-char" "-fgnuc-version=4.2.1" "-target-feature" "+outline-atomics" "-faddrsig" "-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-o" "aarch64-features.o" "-x" "c" "/b/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/aarch64-features.c" 
check:22'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
check:22'1                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 ?                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  possible intended match
>>>>>>

--

********************

https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8794231481315947569/overview

If this will be hard to fix, can you revert until this can be sorted out?

The test was fixed bf94eac6a3f7c5cd8941956d44c15524fa3751bd ( it missed the case that Fuchsia has ToolChain::RLT_CompilerRT as default GetDefaultRuntimeLibType ).
Please let me know if you have any issues remained with the patch.

In D127812#4008451, @paulkirth wrote:

Hi, we're seeing a build failure in Fuchsia's Clang CI. We're seeing this on all of our builders: arm64 & x64 linux, mac and windows

FAILED: CMakeFiles/clang_rt.builtins-aarch64.dir/cpu_model.c.o 
/b/s/w/ir/x/w/recipe_cleanup/cxx-rbevgw5lbzc/reclient-cxx-wrapper.sh /b/s/w/ir/x/w/staging/llvm_build/./bin/clang --target=aarch64-unknown-linux-gnu --sysroot=/b/s/w/ir/x/w/cipd/linux -DHAS_ASM_LSE -DVISIBILITY_HIDDEN  --target=aarch64-unknown-linux-gnu -O2 -g -DNDEBUG -DCOMPILER_RT_HAS_FLOAT16 -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD -MT CMakeFiles/clang_rt.builtins-aarch64.dir/cpu_model.c.o -MF CMakeFiles/clang_rt.builtins-aarch64.dir/cpu_model.c.o.d -o CMakeFiles/clang_rt.builtins-aarch64.dir/cpu_model.c.o -c /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/lib/builtins/cpu_model.c
../../../../llvm-llvm-project/compiler-rt/lib/builtins/cpu_model.c:1233:15: error: use of undeclared identifier 'HWCAP_CPUID'
  if (hwcap & HWCAP_CPUID) {
              ^
1 error generated.

Bot: https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64-rbe/b8794244402291698129/overview

Can you revert if the fix is going to be hard. I imagine in this case the preprocessor logic is slightly off, so a forward fix may be easy.

Thanks for report, fixed in a43f36142c501e2d3f4797ef938db4e0c5e0eeec

Does anyone have any more objections? I'm going to merge it.

Comments have beed addressed.

Addressing comments.

Rebase on top of trunk. Addressed comments. Fixed initFeatureMap issue resulting in some fmv features not enabled on target, use it and AARCH64_ARCH_EXT_NAME for target attribute features dependencies as well.

Stylistics corrections.

Addressing comments and ACLE specification updates.
sme-f64 -> sme-f64f64 and sme-i64 -> sme-i16i64 features are expected to be renamed in specification.

@sebpop could you ellaborate on __sync_* operations usage, are you getting issues with current Clang implementation? Do Clang need to keep supporting them and fix introducing new memory model? It seems we need compelling reasons to do that.

Commited in af6d2a0b6825e71965f3e2701a63c239fa0ad70f

Addressing comments, stylistic corrections.

In D127812#3585249, @erichkeane wrote:

I'm concerned as to the design of this addition, I don't particularly appreciate the reasons for making 'target_clones' different, nor the purpose for adding a new attribute instead of using 'target' for what seems like exactly that? IF the new spelling is THAT necessary, we perhaps don't need a whole new attribute for it either.

Thank you for fair concern, "target_clones" for AArch64 has different format, semantic, e.g. "default" is not required. Therefore it diverges with X86 in these parts. "target" attribute has been already used and supported on AArch64 in a different sense, like target("arm"), target("dotprod"), target("branch-protection=bti"). The intention of creating new "target_version" attribute is not to overlap with that. It also has different format, mangling and semantic, e.g. treating function without attribute as "default", and option to disable attribute droping function multi versions. Do these explanations dispel your concern?

I think it looks reasonable to define 5th memory model, add barriers __sync_* builtins and to outline-atomics calls as well.

Just a friendly ping. Jessica @paquette, do you have any further suggestions?