Iain Sandoe <i...@sandoe.co.uk> writes: > Hi Richard, > > > I am being bitten by a problem that falls out from the code that emits > > .arch Armv8.n-a+crc > > when the arch is less than Armv8-r. > The code that does this, in gcc/common/config/aarch64 is quite recent > (2022-09).
Heh. A workaround for one assembler bug triggers another assembler bug. The special treatment of CRC is much older than 2022-09 though. I think it dates back to 04a99ebecee885e42e56b6e0c832570e2a91c196 (2016-04), with 4ca82fc9f86fc1187ee112e3a637cb3ca5d2ef2a providing the more complete explanation. > > ------ > > (I admit the permutations are complex and I might have miss-analyzed) - but > it appears that llvm assembler (for mach-o, at least) sees an explict mention > of an attribute for a feature which is mandatory at a specified arch level as > demoting that arch to the minimum that made the explicit feature mandatory. > Of course, it could just be a bug in the handling of transitive feature > enables... > > the problem is that, for example: > > .arch Armv8.4-a+crc > > no longer recognises fp16 insns. (and appending +fp16 does not fix this). > > ==== > > Even if upstream LLVM is deemed to be buggy (it does not do what I would > expect, at least), and fixed - I will still have a bunch of assembler > versions that are broken (before the fix percolates through to downstream > xcode) - and the LLVM assembler is the only current option for Darwin. > > So, it seems that this ought to be a reasonable configure test: > > .arch armv8.2-a > .text > m: > crc32b w0, w1, w2 > > and then emit HAS_GAS_AARCH64_CRC_BUG (for example) if that fails to assemble > which can be used to make the +crc emit conditional on a broken assembler. AIUI the problem was in the CPU descriptions, so I don't think this would test for the old gas bug that is being worked around. Perhaps instead we could have a configure test for the bug that you've found, and disable the crc workaround if so? Thanks, Richard > > - I am asking here before constructing the patch, in case there’s some reason > that doing this at configure time is not acceptable. > > thanks > Iain
