Build the C builtins without C library headers - #3977

Thanks, this looks good. There are several little things worth cleaning up before merging:

1. The m4 builtins still pipe into llvm-as (cmake/GenerateBuiltins.cmake:94-95)

COMMAND ${M4_EXECUTABLE} -I${include} -DBUILD_OS=${OS_UP} -DRUNTIME=${bit} ${input}
    | \"${LLVM_AS_EXECUTABLE}\" -o ${bc}

This is the same issue the PR fixes for the C builtins. The pipe drops m4's exit status, and llvm-as exits 0 on empty input, writing a valid empty module. svml.m4, util.m4 and util-xe.m4 stop on purpose with errprint + m4exit(1), so those errors are hidden too, as long as the output up to that point still assembles. Could m4 write to an intermediate .ll first, then llvm-as ${ll} -o ${bc}? Similarly, cat ${input} | llvm-as -o ${bc} in builtin_xe_to_cpp (line 342) could just be llvm-as ${input} -o ${bc}.

2. arm_macos_cross.ispc needs MACOS_HOST too (tests/lit-tests/arm_macos_cross.ispc:6)

The PR adds MACOS_HOST to arm64_macos.ispc and arm64_macos_cross.ispc, but not to the ARM32 version. Its first RUN line uses --target-os=linux, so on a Linux ARM host lGetARMDeviceType() sees no cross compilation and detects the host CPU (e.g. cortex-a53), while line 9 expects cortex-a35. Since MACOS_ARM_ENABLED no longer depends on the SDK version, -DISPC_MACOS_TARGET=ON on a Linux ARM host is enough to hit this:

// REQUIRES: MACOS_HOST && ARM32_ENABLED && MACOS_ARM_ENABLED && LINUX_ENABLED

Nits

• Dead MinGW branch. builtins/builtins-c-cpu.cpp:178: the __MINGW32__ half of #if defined(_MSC_VER) || defined(__MINGW32__) can no longer compile, because MinGW without _MSC_VER hits the #error at line 63 first. No configured triple uses MinGW, so __MINGW32__ can be dropped there (or a MinGW branch added if it is meant to be supported).
• MACOS_ARM_ENABLED. CMakeLists.txt:229: ISPC_MACOS_ARM_TARGET is now always equal to ISPC_MACOS_TARGET, so the MACOS_ARM_ENABLED lit feature no longer says anything separate. What actually decides whether macOS ARM builtins are built is ISPC_MACOS_TARGET AND ARM_ENABLED. Defining it as that condition (or removing it) would also make tests like cpu_arm.ispc and ftz_daz_flags_aarch64.ispc (!MACOS_HOST || MACOS_ARM_ENABLED) correct with ARM_ENABLED=OFF.
• Termux ARM32_ENABLED=OFF. .github/workflows/scripts/build-ispc-termux.sh:23 keeps the flag, but the comment explaining it was removed, along with the one for ARM32_ENABLED in CMakeLists.txt. The original reason, missing 32-bit ARM headers, no longer applies. Either enable ARM32 so Termux CI covers the header-independent ARM32 builtins, or say why it stays off.
• Leftover GNUWIN32 settings.
  • .github/workflows/scripts/init-env.ps1:18-20 still sets CROSS_TOOLS_GNUWIN32.
  • reusable.ispc.build.yml:209,219, pre-release-artifacts.yml:101 and rk-superbuild.yml:64 still pass -DGNUWIN32=%CROSS_TOOLS_GNUWIN32%.
  • Superbuild now only uses GNUWIN32 for LLVM's LIT_TOOLS_DIR (superbuild/CMakeLists.txt:205), and CI no longer populates that directory.
• Linux cross packages. .github/workflows/scripts/install-build-deps.sh:43,46 still installs libc6-dev-armhf-cross, gcc-*-cross-base and similar packages, which were mainly needed for the builtin headers (including the RISC-V --sysroot). Some may still be needed to link or run tests, so it's worth checking which ones can go.