Building `compiler-rt` (LLVM/clang 22.1.3) for a 32-bit ARM target without Thumb-2 (e.g. TUNE=arm926ejs, ARMv5TE, no Thumb-2) fails with: arm/divsf3.S:206:3: error: invalid instruction, any one of the following would fix this: mls r1, r0, r3, r1 note: instruction requires: armv6t2 note: instruction requires: thumb2 Root cause: compiler-rt_git.bb passes -DCMAKE_C_COMPILER_TARGET=${HOST_SYS}, which for every 32-bit ARM tune resolves to the same generic triple "arm-oe-linux-musleabi". As a result, lib/builtins/CMakeLists.txt selects BUILTIN_SUPPORTED_ARCH="arm"->arm_SOURCES instead of the correct armv5te_SOURCES/armv6_SOURCES. Steps to reproduce: 1. MACHINE using an ARM tune without Thumb-2, e.g. arm926ejs (conf/machine/include/arm/armv5/tune-arm926ejs.inc) 2. TOOLCHAIN = "clang" so clang is used as the target compiler 3. bitbake compiler-rt Workaround compiler-rt_git.bbappend: EXTRA_OECMAKE:append:armv4 = " -DCOMPILER_RT_ARM_OPTIMIZED_FP=OFF" EXTRA_OECMAKE:append:armv5 = " -DCOMPILER_RT_ARM_OPTIMIZED_FP=OFF" EXTRA_OECMAKE:append:armv6 = " -DCOMPILER_RT_ARM_OPTIMIZED_FP=OFF"
This looks a lot like an upstream clang problem, would you be able to replicate it outside of yocto? Until it's root-caused, your workaround is fine. Would you be able to send a patch to add that to the compiler-rt recipe? Marking as NEEDINFO status, if you are able to send a patch please do so and switch the bug to ACCEPTED. Thanks!
Ah, is this related to this function: def get_compiler_rt_arch(bb, d): if bb.utils.contains('TUNE_FEATURES', 'armv5 thumb dsp', True, False, d): return 'armv5te' elif bb.utils.contains('TUNE_FEATURES', 'armv4 thumb', True, False, d): return 'armv4t' elif bb.utils.contains('TUNE_FEATURES', 'arm vfp callconvention-hard', True, False, d): return 'armhf' return d.getVar('HOST_ARCH') If no thumb it will fallback to HOST_ARCH, when it should be passing different values?
(In reply to Ross Burton from comment #2) > Ah, is this related to this function: > > def get_compiler_rt_arch(bb, d): > if bb.utils.contains('TUNE_FEATURES', 'armv5 thumb dsp', True, False, d): > return 'armv5te' > elif bb.utils.contains('TUNE_FEATURES', 'armv4 thumb', True, False, d): > return 'armv4t' > elif bb.utils.contains('TUNE_FEATURES', 'arm vfp callconvention-hard', > True, False, d): > return 'armhf' > return d.getVar('HOST_ARCH') > > If no thumb it will fallback to HOST_ARCH, when it should be passing > different values? Yeah, that's also wrong but CMake isn't using the value passed via `COMPILER_RT_DEFAULT_TARGET_ARCH` as far as I can see. Setting the correct arch type in ` CMAKE_C_COMPILER_TARGET` fixes the problem in my test (even if `COMPILER_RT_DEFAULT_TARGET_ARCH` is not set at all). I think that is a better approach than my previous workaround. I could provide a patch for that hopefully next week. (In reply to Ross Burton from comment #1) > This looks a lot like an upstream clang problem, would you be able to > replicate it outside of yocto? > > Until it's root-caused, your workaround is fine. Would you be able to send a > patch to add that to the compiler-rt recipe? > > Marking as NEEDINFO status, if you are able to send a patch please do so and > switch the bug to ACCEPTED. Thanks! Honestly, the CMake files of compiler-rt are so complicated that I can't say if that's a bug from Yocto or them... You can see in the Yocto CMake configure logs that compiler-rt is build for the wrong target (arm), so this should be replicateable outside of Yocto but my clang does support all backends and therefore doesn't fail.