This patch series should have no functional change besides the mangling of some symbol names on AArch64.
Patch 1/5 adds lots of tests to verify that existing mangling behaviour on x86 and PowerPC is unchanged. Patch 2/5 extends DECL_FUNCTION_VERSIONED to a 2-bit enum. Patches 3/5 and 4/5 are trivial refactorings. Patch 5/5 is the only patch with any functional change, and that should be minimal. I've bootstrapped and tested the entire series on both AArch64 and x86. I've also run the new x86 and PowerPC tests on a cross-compiler (with a temporary hack to disable ifunc availability checks) to verify that function multiversioning still works on those platforms, with the symbol mangling unchanged. I'm aware now that we just started of Stage 4, and this isn't actually a regression, but is this still ok for master? Some other things I previously tried that I couldn't make work: - I had hoped to create an explicit target hook for the ifunc symbol name mangling as well, but it turned out to be rather tricky to replicate the existing double mangling weirdness for x86 (I didn't work out how to convince the frontend to apply C++ mangling to the new symbol on-demand without breaking other things). - It's also awkward to try to access the base assembler name after applying function version mangling - this is why I resorted to just reversing the default version mangling in the AArch64 backend. I tried delaying function version mangling until after the resolver was generated, but that led to issues with duplicate comdat group names from make_decl_one_only. There may be less hacky solutions or workarounds for these issues, but they would involve a more substantial refactoring and will have to wait until GCC 15 (or later).