On Thu, Jul 16, 2026 at 04:20:14PM +0100, Iain Sandoe wrote: > Hi Alice, > > > On 16 Jul 2026, at 16:06, Alice Carlotti <[email protected]> wrote: > > > > On Thu, Oct 26, 2023 at 08:31:04PM +0100, Iain Sandoe wrote: > >> This is an enablement patch (the initial use comes with the Darwin aarch64 > >> port). Tested on aarch64-linux-gnu, aarch64-apple-darwin and x86_64-darwin > >> just for good measure, OK for trunk? > >> thanks > >> Iain. > >> > >> --- 8< --- > >> > >> Some assmblers have a bug that requires +crc to be emitted even > >> though the base architecture supports it. However, that also > >> triggers a different bug in another assembler. So make the fix > >> configurable. > > > > I only just noticed this, sorry, but I don't think it's as straightforward > > as > > "triggers a different bug in another assembler". It's actually "avoids > > triggering one bug in another assembler, which means we hit a different bug > > in > > that assembler more often". I described the bugs in detail in > > https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674446.html. > > > > There's no sensible way to workaround both of those bugs at the same time. > > The > > effect of this patch is that some .arch directives will be ignored, instead > > of > > being applied with missing features. In some cases this helps (if the .arch > > directive includes unrecognised feature names that will be incorrectly > > dropped, > > and there are no recognised optional features specified). In other cases > > (likely much rarer), this patch makes things worse (if the .arch directive > > specifies a higher architecture version, with only the mandatory > > architecture > > features present). > > > > Given that the broken Binutils versions don't support Darwin, I think it's > > fine > > to disable the CRC workaround when targetting Darwin, or if we otherwise > > know > > that we're using an old LLVM version for assembly. This will improve the > > likelihood of being able to assemble the resulting output with LLVM <=16, > > but > > it's still going to break sometimes, and realistically the best option is to > > avoid using LLVM <=16 (or other assemblers without the LLVM 17 fixes) for > > assembly if at all possible. > > > > To be clear - I have no objection to this patch remaining in (or being > > replaced > > with a patch that disables the workaround for Darwin), but I wanted to make > > clear that the situation is more nuanced than your commit message suggests. > > As things stand, the DISABLE_AARCH64_AS_CRC_BUGFIX is only set in > my (currently out-of-tree) development branch for aarch64-darwin: > > aarch64-*-darwin* ) > tm_file="${tm_file} aarch64/aarch64-errata.h" > tmake_file="${tmake_file} aarch64/t-aarch64 aarch64/t-aarch64-darwin" > tm_defines="${tm_defines} TARGET_DEFAULT_ASYNC_UNWIND_TABLES=1" > tm_defines="${tm_defines} DISABLE_AARCH64_AS_CRC_BUGFIX=1" > # Choose a default CPU version that will work for all current > releases. > with_cpu=${with_cpu:-apple-m1} > ;; > > I guess that linux ports could detect an LLVM version (we already do this in > gcc/configure for Darwin, since there are other dependencies) and then apply > the same for earlier versions?
Do you mean "don't apply the workaround if configured with LLVM <= 16 as the assembler"? That's probably ok, but it still doesn't fix behaviour with old LLVM, and I doubt it's common enough to be worth adding a specific check for that case (especially if we've given a way for someone to override it manually when configuring the build). > > Maybe I’m mixing up negatives; > Are you saying the if Darwin is using an assembler based on LLVM >= 17 then > the fix can be left in place and llvm backend will cope OK? Yes, as far as I'm aware LLVM >= 17 works correctly, with or without the +crc workaround applied. LLVM <= 16 is broken both with and without the workaround, but I think you're more likely to get successful assembly without the workaround. Alice > > I ask because this also has some impact on the testsuite - which i’m in the > process > of tidying on the journey to posting the port … > > Iain > > > > > Alice > > > > > >> > >> gcc/ChangeLog: > >> > >> * common/config/aarch64/aarch64-common.cc: Make the asm > >> crc bug workaround configurable. > >> > >> Signed-off-by: Iain Sandoe <[email protected]> > >> --- > >> gcc/common/config/aarch64/aarch64-common.cc | 8 ++++++-- > >> 1 file changed, 6 insertions(+), 2 deletions(-) > >> > >> diff --git a/gcc/common/config/aarch64/aarch64-common.cc > >> b/gcc/common/config/aarch64/aarch64-common.cc > >> index 20bc4e1291b..4922a6b235c 100644 > >> --- a/gcc/common/config/aarch64/aarch64-common.cc > >> +++ b/gcc/common/config/aarch64/aarch64-common.cc > >> @@ -301,8 +301,12 @@ aarch64_get_extension_string_for_isa_flags > >> > >> However, assemblers with Armv8-R AArch64 support should not have this > >> issue, so we don't need this fix when targeting Armv8-R. */ > >> - auto explicit_flags = (!(current_flags & AARCH64_FL_V8R) > >> - ? AARCH64_FL_CRC : 0); > >> + aarch64_feature_flags explicit_flags = > >> +#ifndef DISABLE_AARCH64_AS_CRC_BUGFIX > >> + (!(current_flags & AARCH64_ISA_V8R) ? AARCH64_FL_CRC : 0); > >> +#else > >> + 0; > >> +#endif > >> > >> /* Add the features in isa_flags & ~current_flags using the smallest > >> possible number of extensions. We can do this by iterating over the > >> -- > >> 2.39.2 (Apple Git-143) > >> >
