Zlib-ng compilation fails on Raspbian ARM32 system

[filipnavara]

Log output:

  fatal error: error in backend: Cannot select: intrinsic %llvm.arm.uqsub16
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.    Program arguments: /usr/bin/clang-16 -DARM_ACLE -DARM_ASM_HWCAP -DARM_AUXV_HAS_CRC32 -DARM_AUXV_HAS_NEON -DARM_FEATURES -DARM_NEON -DARM_NEON_HASLD4 -DARM_SIMD -DARM_SIMD_INTRIN -DBUILDENV_DEBUG=1 -DCLR_ARM_FPU_CAPABILITY=0x7 -DCOMPILER_SUPPORTS_W_RESERVED_IDENTIFIER -DDEBUG -DDISABLE_CONTRACTS -DHAVE_ALIGNED_ALLOC -DHAVE_ARM_ACLE_H -DHAVE_ATTRIBUTE_ALIGNED -DHAVE_BUILTIN_CTZ -DHAVE_BUILTIN_CTZLL -DHAVE_POSIX_MEMALIGN -DHAVE_SYS_AUXV_H -DHAVE_VISIBILITY_HIDDEN -DHAVE_VISIBILITY_INTERNAL -DHOST_ARM -DHOST_UNIX -DPALEXPORT=EXTERN_C -DTARGET_32BIT -DTARGET_ARM -DTARGET_LINUX -DTARGET_UNIX -DURTBLDENV_FRIENDLY=Debug -DWITH_GZFILEOP -DZLIB_COMPAT -D_DBG -D_DEBUG -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1 -D_TIME_BITS=64 -D__USE_LARGEFILE64 -I/home/navara/runtime/artifacts/obj/coreclr/linux.arm.Debug/_deps/fetchzlibng-build -I/home/navara/runtime/src/native/external/zlib-ng -I/home/navara/runtime/src/native -I/home/navara/runtime/src/native/inc -std=gnu99 -Wno-declaration-after-statement -D_GNU_SOURCE -g -fPIC -O0 -Wall -Wno-null-conversion -glldb -fno-omit-frame-pointer -fwrapv -fstack-protector-strong -Werror -Wno-unused-variable -Wno-unused-value -Wno-unused-function -Wno-tautological-compare -Wno-unknown-pragmas -Wimplicit-fallthrough -Wno-unused-but-set-variable -ffp-contract=off -Wno-unknown-warning-option -ferror-limit=4096 -Wno-unused-private-field -Wno-constant-logical-operand -Wno-pragma-pack -Wno-incompatible-ms-struct -Wno-reserved-identifier -Wno-unsafe-buffer-usage -Wno-single-bit-bitfield-constant-conversion -Wno-cast-function-type-strict -Wno-switch-default -fsigned-char -fvisibility=hidden -ffunction-sections -mthumb -mfpu=vfpv3 -march=armv7-a -I/home/navara/runtime/src/native/libs/Common -I/home/navara/runtime/artifacts/obj/coreclr/linux.arm.Debug/libs-native/Common -mfloat-abi=hard -DZLIB_DEBUG -Wno-unused-command-line-argument -Wno-logical-op-parentheses -std=c11 -march=armv6 -fno-lto -MD -MT _deps/fetchzlibng-build/CMakeFiles/zlib.dir/arch/arm/slide_hash_armv6.c.o -MF CMakeFiles/zlib.dir/arch/arm/slide_hash_armv6.c.o.d -o CMakeFiles/zlib.dir/arch/arm/slide_hash_armv6.c.o -c /home/navara/runtime/src/native/external/zlib-ng/arch/arm/slide_hash_armv6.c
  1.    <eof> parser at end of file
  2.    Code generation
  3.    Running pass 'Function Pass Manager' on module '/home/navara/runtime/src/native/external/zlib-ng/arch/arm/slide_hash_armv6.c'.
  4.    Running pass 'ARM Instruction Selection' on function '@slide_hash_chain'
  clang: error: clang frontend command failed with exit code 70 (use -v to see invocation)
  Debian clang version 16.0.6 (15~deb12u1)
  Target: arm-unknown-linux-gnueabihf
  Thread model: posix
  InstalledDir: /usr/bin
  clang: note: diagnostic msg: 
  ********************

  PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
  Preprocessed source(s) and associated run script(s) are located at:
  clang: note: diagnostic msg: /tmp/slide_hash_armv6-72b11a.c
  clang: note: diagnostic msg: /tmp/slide_hash_armv6-72b11a.sh
  clang: note: diagnostic msg: 

  ********************
  [ 20%] Built target eventpipe-shared-objects
  make[3]: *** [_deps/fetchzlibng-build/CMakeFiles/zlib.dir/build.make:552: _deps/fetchzlibng-build/CMakeFiles/zlib.dir/arch/arm/slide_hash_armv6.c.o] Error 1

The problem boils down to this:

int main()
{
    return __builtin_arm_uqsub16(0, 0);
}

The build system tries to compile it with something akin to clang -cc1 -triple thumbv7-unknown-linux-gnueabihf -target-cpu arm1136jf-s -emit-obj test.c / clang -march=armv6 -mthumb -c test.c.

It compiles to Thumb instruction set, like the rest of the runtime, but selects an ARMv6 processor. That's an invalid combination for the uqsub16 instruction. It exists in the ARM mode, and it exists in Thumb2 which is available on newer processors. I am not sure what was the intent, CoreCLR is not supported on ARMv6 cores, so the selection of arm1136jf-s makes no sense. The newer Raspberry Pis supported by CoreCLR are ARMv7 and have Thumb2 instructions.

[dotnet-policy-service[bot]]

Tagging subscribers to this area: @hoyosjs See info in area-owners.md if you want to be subscribed.

[filipnavara]

It's likely combination of this Cmake check which checks and adds -march=armv6, while not using -mthumb inside the check_c_source_compiles macro:

https://github.com/dotnet/runtime/blob/28f729b437590bd34bbdca79bd3f2b6a504b4dcb/src/native/external/zlib-ng/cmake/detect-intrinsics.cmake#L36-L74

[filipnavara]

cc @carlossanlop

[dotnet-policy-service[bot]]

Tagging subscribers to this area: @dotnet/area-system-io-compression See info in area-owners.md if you want to be subscribed.

[carlossanlop]

It's likely combination of this Cmake check which checks and adds -march=armv6, while not using -mthumb inside the check_c_source_compiles macro:

https://github.com/dotnet/runtime/blob/28f729b437590bd34bbdca79bd3f2b6a504b4dcb/src/native/external/zlib-ng/cmake/detect-intrinsics.cmake#L36-L74

Sounds like we should also get an issue opened in the zlib-ng repo to report this. Would you mind doing that?

[filipnavara]

Sounds like we should also get an issue opened in the zlib-ng repo to report this. Would you mind doing that?

It's not an issue for upstream zlib-ng though because it's not compiled with -mthumb. That's inherited from the CoreCLR build system. Arguably the flag could be passed to the check_armv6_compiler_flag check somehow but I am not sure if there's canonical way to do it in Cmake.