Is this a buildsystem bug in the kernel configuration? (qualcommax/ipq807x)

I recently built a custom opwnwrt firmware for the dynalink wrx36. While it was compiling I noticed something weird...When the kernel was compiling, the following flags were being added to the GCC command:

-DASM_ARM_ARCH="arm8.5-a" -Wa,-march="arm8.5-a"

Now, from what I can gather, all ipq807x SoC's use a cortex-a53, and all cortex-a53's fully support only the armv8-a target and not any of the arm8.X-a targets **

**

** not fully at least...support varies on an extension-by-extension basis. Moving up to a higher arm8.X-a target means that more of these extensions are enabled by default (all the extensions of the lower arm8.X-a target plus a few new ones). But. many extensions are compatible with lower arm8.X-a targets but not enabled by default until the higher arm8.X-a target.

As such, it might be possible (particularly if the "enabled defaults" are different for the assembler than they are for gcc) to increase the target arch to a higher arm8.X-target and only by default enable extensions that the current (lower) arm8.X-a target is already compatible with. It also might be that, specifically for the assembler, listing a higher arch (while also giving a -mcpu=cortex-a53) doesnt end up doing any harm / trying to use incompatible extensions. i.e., I dont actually know if this is a bug or a clever optimization.

I was going to report this as a bug but then realized I didnt actually know for sure if this was a bug....Anyone more familiar with gcc's internal working than I am here who can tell me if it is or not?

Thanks in advance.


INFO ON WHAT IS CAUSING THIS TO OCCUR

I dug into what was triggering this being added to the compile options. It appears to be that the Makefile at <kernel build directory root>/arch/arm64/Makefile. This is happening in response to something adding

CONFIG_AS_HAS_ARMV8_5=y

to the kernel config (analogous kernel config options for 8.1, 8.2, 8.3, and 8.4 are also being added). This is where I stropped digging and edited the arch/arm64/Makefile with

asm-arch := armv8-a

just after it did all the checks for the arm8.{1..5}-a extensions, making it instead pass compiler flags

-DASM_ARM_ARCH="arm8-a" -Wa,-march="arm8-a"

Does it really stop compiling unless you correct it?

Are you compiling for K6.1?

No, it still compiles. But, its my understanding that if you use unsupported instructions on ARM itll still compile and run, just much more slowly (something like "it tries to use the unsupported instructions, fails, and then takes some generic 'backup' codepath").

Its more a matter of optimization and making sure the kernel isnt much slower than it could be if the correct instruction set was used.

That said, it'll compile, but IDK if the firmware image that the build system actually produces will run and be stable or not...in the couple of firmware images that ive built and then actually flashed to my WRX36 ive manually changed it to armv8-a+crc+crypto, to match my GCC optimization CFLAGS -mcpu=cortex-a53+crc+crypto.

Its also worth noting that I have the "sparse" checker enabled for the kernel build. And, while I havent quantatitively compared this, it seems like sparse is throwing out a good number more warnings when i dont change it and allow it to use the armv8.5-a flag.

yes. from snapshot builds within the last week or so.

I compile for 23.05.2 snapshot and that runs fine, I checked it also has the:

But whether is is detrimental for the build speed or otherwise I do not know