https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70133
James Greenhalgh <jgreenhalgh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
CC| |jgreenhalgh at gcc dot gnu.org
--- Comment #5 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> ---
The crux of this issue is going to be that your Cortex-A53 has no support for
the cryptography extension, but does have support for the CRC extensions.
By inspection of host_detect_local_cpu, I see that we run through all the
extensions that we know about, checking to see whether that extension is a
substring of the Features we read from /proc/cpuinfo . If it is we add
+extension, if not we add +noextension.
So, it seems reasonable to me that if we run this algorithm on a core without
crypto, but with CRC, we'll get the string described
(-march=armv8-a+fp+simd+nocrypto+crc+nolse) forwarded to the assembler on
command line.
And sure enough, the assembler wants to read everything you've got before you
start telling it what you've not got.
I see a few issues.
1) There's not really a good reason for an assembler to have this syntax
restriction. The code does the right thing whatever order you put your features
in.
2) We'll have to support these older assemblers anyway, so at the least we'll
have to hold off writing the "+no" extension strings until we're done with the
"+" extension strings.
3) We should think about whether we need to put out these +no extension strings
at all. I don't like that for my older systems I'll need to keep updating my
binutils to cover any new extension strings (e.g. +nolse) that are added by GCC
if I want to use -march=native . We shouldn't force that if we don't have to.
So, Confirmed.
