https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99698
Bug ID: 99698
Summary: [aarch64] Impossible to accurately detect extensions
using preprocessor
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
Using SHA3 as an example, but this problem exists for other extensions as well.
If you pass something like -march=armv8-a+sha3, GCC will define
__ARM_FEATURE_SHA3. According to the ACLE documentation:
__ARM_FEATURE_SHA3 is defined to 1 if the SHA1 & SHA2 Crypto instructions
from Armv8-A and the SHA2 and SHA3 instructions from Armv8.2-A and newer
are supported and intrinsics targeting them are available. These
instructions include AES{E, D}, SHA1{C, P, M}, RAX, and others.
So, I should be able to use the preprocessor to call a function like vbcaxq_u32
if __ARM_FEATURE_SHA3 is defined to 1.
However, if I call vbcaxq_u32 I get an error about a target specific option
mismatch. It turns out that you need -march=armv8.2-a+sha3 to convince GCC to
accept the function call.
AFAICT there is no way to reliably detect armv8.2-a. The only difference in
the preprocessor macros defined for armv8-a and armv8.2-a are a few extra
__ARM_FEATURE_* macros. There is *no* difference in pre-defined macros between
armv8.1-a and armv8.2-a.
FWIW, clang accepts -march=armv8-a+sha3, defines __ARM_FEATURE_SHA3 to 1, and
allows you to call the SHA3 functions, which seems pretty reasonable to me.
