754345d606
When crypto is not in tune features then add +nocryto to -mcpu explicitly. This makes the behavior between clang and gcc match. Currently -mcpu=cortex-a72 has different behavior in clang and gcc in terms of what features are considered default. Clang enables different set of common features than gcc on other hand. For example clang enables crypto with default set but gcc does not, gcc recommends to disable unavailable extensions in -mcpu [1] explicitly. crypto is optional on cortex-a53 and cortex-a72. This is not as common but Broadcom SOCs in raspberrypi3/4 have dropped crypto for cost reasons [2]. This results in illegal instruction traps [3] [4] when building components e.g. chromium, qtwebengine, weston etc. with clang using -mcpu=cortex-a72 for rpi4 target. Adding +nocrypto makes clang behave like gcc does today. We do have separate tune if crypto enabled cortex-a72 cores are to be targeted (cortexa72-cryto) as DEFAULTTUNE They are added to default feature file since crypto extension is available in multiple arm architecture versions e.g. armv8, armv9. It is optional extension as per spec [5] Extensions can be enabled and disabled with -mcpu using the same syntax as with -march, and have same effect thats why it is intrumented via TUNE_CCARGS_MARCH_OPTS [1] https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html#index-mcpu-2 [2] https://forums.raspberrypi.com/viewtopic.php?f=63&t=207888#p1332960 [3] https://github.com/llvm/llvm-project/issues/85699 [4] https://github.com/llvm/llvm-project/issues/90365 [5] https://developer.arm.com/documentation/109697/2025_06/Feature-descriptions/The-Armv9-0-architecture-extension (From OE-Core rev: db1b355b2b15ba57bd89c2dfb88c2c667551863e) Signed-off-by: Khem Raj <raj.khem@gmail.com> Cc: Quentin Schulz <quentin.schulz@cherry.de> Acked-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012/03/30 - Mark Hatle mark.hatle@windriver.com
- Initial Revision
The ARM architecture definitions are split among a number of files. The primary definitions for the variables are handled by the core arch-arm.inc file.
TUNE_ARCH is set to either "arm" or "armeb" depending on the value of the existence of the "bigendian" feature in a given tune.
A small set of ARM specific variables have been defined to allow TUNE_PKGARCH to be automatically defined. Optimized tunings must NOT change the definiton of TUNE_PKGARCH. TUNE_PKGACH:tune- will be ignored. The format of the package arch is enforced by the TUNE_PKGARCH default. The format must be of the form: [t][e][hf][b][-vfp][-neon]
TUNE_PKGARCH is defined as: ${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}
ARMPKGARCH - This is the core package arch component specified by each tuning. This is the primary identifier of a tuning. Usual values are: arm, armv4, armv5, armv6, armv7a, etc.
ARMPKGSFX_THUMB - This is the thumb specific suffix. Curently it is defined in feature-arm-thumb.inc.
ARMPKGSFX_DSP - This is the DSP specific suffix. Currently this is set to 'e' when on armv5 and the dsp feature is enabled.
ARMPKGSFX_EABI - This is the eabi specific suffix. There are currently
two defined ABIs specificed, standard EABI and Hard Float (VFP) EABI.
When the callconvention-hard is enabled, "hf" is specified, otherwise it
is blank.
ARMPKGSFX_ENDIAN - This is the endian specific suffix. It is defined in the core arch-arm.inc file.
ARMPKGSFX_FPU - This is the FPU specific suffix. The suffix indicates specific FPU optimizations. 'vfp' and 'neon' are both defined.