[compiler-rt] COMPILER_RT_DEFAULT_TARGET_ONLY should explicitly pass the triple to test

[ndrewh]

COMPILER_RT_DEFAULT_TARGET_ONLY normally requires CMAKE_C_COMPILER_TARGET, which ensures that CMake builds with the specified target triple (e.g. by CMake automatically appending the -target flag)

However, when running tests no target triple is currently passed. This can cause issues (#176913) when the default architecture assumed by clang (i.e. the host architecture) does not match the architecture being tested -- for example i386 on x86_64. To solve this, we add -target to the cflags used for the tests as well.

Closes #176913

rdar://172833755

[zmodem]

I tried this with the repro form #176913 and it doesn't build:

cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=clang -DLLVM_ENABLE_RUNTIMES=compiler-rt -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF -DBUILTINS_i386-pc-windows-msvc_LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF -DRUNTIMES_i386-pc-windows-msvc_COMPILER_RT_BUILD_CRT=OFF -DRUNTIMES_i386-pc-windows-msvc_COMPILER_RT_BUILD_LIBFUZZER=OFF -DRUNTIMES_i386-pc-windows-msvc_COMPILER_RT_BUILD_CTX_PROFILE=OFF -DRUNTIMES_i386-pc-windows-msvc_COMPILER_RT_BUILD_MEMPROF=OFF -DRUNTIMES_i386-pc-windows-msvc_COMPILER_RT_BUILD_ORC=OFF -DRUNTIMES_i386-pc-windows-msvc_COMPILER_RT_BUILD_PROFILE=OFF -DRUNTIMES_i386-pc-windows-msvc_COMPILER_RT_BUILD_SANITIZERS=OFF -DRUNTIMES_i386-pc-windows-msvc_COMPILER_RT_BUILD_XRAY=OFF -DRUNTIMES_i386-pc-windows-msvc_COMPILER_RT_DEFAULT_TARGET_ONLY=ON -DLLVM_BUILTIN_TARGETS=i386-pc-windows-msvc -DLLVM_RUNTIME_TARGETS=i386-pc-windows-msvc ../llvm
ninja check-runtimes
...
[1/127] Building C object CMakeFiles\clang_rt.builtins-i386.dir\absvsi2.c.obj
FAILED: CMakeFiles/clang_rt.builtins-i386.dir/absvsi2.c.obj
C:\src\llvm-project\build.123\.\bin\clang-cl.exe --target=i386-pc-windows-msvc  /nologo  -IC:\src\llvm-project\compiler-rt\lib\builtins\..\..\..\third-party\siphash\include /DWIN32 /D_WINDOWS /O2 /Ob2 /DNDEBUG -arch i386 -fno-lto -Wno-c2y-extensions /Zl -fno-builtin -DCOMPILER_RT_HAS_FLOAT16 /showIncludes /FoCMakeFiles\clang_rt.builtins-i386.dir\absvsi2.c.obj /FdCMakeFiles\clang_rt.builtins-i386.dir\clang_rt.builtins-i386.pdb -c -- C:\src\llvm-project\compiler-rt\lib\builtins\absvsi2.c
clang-cl: warning: unknown argument ignored in clang-cl: '-arch' [-Wunknown-argument]
clang-cl: error: cannot specify '/FoCMakeFiles\clang_rt.builtins-i386.dir\absvsi2.c.obj' when compiling multiple source files
clang-cl: warning: i386: 'linker' input unused [-Wunused-command-line-argument]

[ndrewh]

@zmodem Could you try again now? This seems to work for me now on linux with your cmdline except s/i386-pc-windows-msvc/i386-linux-unknown/

i.e. it looks like tests are running with the explicit -target:

Command Output (stdout):
--
# RUN: at line 1
/code/build_vessel/./bin/clang   -gline-tables-only  -target i386-unknown-linux-unknown  -fno-builtin -I /code/compiler-rt/lib/builtins -nodefaultlibs /code/compiler-rt/test/builtins/Unit/floatdidf_test.c /code/build_vessel/./lib/../lib/clang/23/lib/linux/libclang_rt.builtins-i386.a -lc -lm -o /code/build_vessel/runtimes/runtimes-i386-linux-unknown-bins/compiler-rt/test/builtins/Unit/I386LinuxConfig/Output/floatdidf_test.c.tmp &&  /code/build_vessel/runtimes/runtimes-i386-linux-unknown-bins/compiler-rt/test/builtins/Unit/I386LinuxConfig/Output/floatdidf_test.c.tmp

[zmodem]

Now it gets further, but it fails to link the 32-bit crt:

FAIL: Builtins-i386-windows :: absvti2_test.c (59 of 228, 3 of 3 attempts)
******************** TEST 'Builtins-i386-windows :: absvti2_test.c' FAILED ********************
Exit Code: 1120

Command Output (stdout):
--
# RUN: at line 1
C:/src/llvm-project/build.123/./bin/clang.exe   -gline-tables-only -gcodeview -gcolumn-info  -target i386-pc-windows-msvc  -fno-builtin -I C:/src/llvm-project/compiler-rt\lib\builtins -nodefaultlibs C:\src\llvm-project\compiler-rt\test\builtins\Unit\absvti2_test.c C:/src/llvm-project/build.123/./lib/../lib/clang/23/lib/windows\clang_rt.builtins-i386.lib -o C:\src\llvm-project\build.123\runtimes\runtimes-i386-pc-windows-msvc-bins\compiler-rt\test\builtins\Unit\I386WindowsConfig\Output\absvti2_test.c.tmp &&  C:\src\llvm-project\build.123\runtimes\runtimes-i386-pc-windows-msvc-bins\compiler-rt\test\builtins\Unit\I386WindowsConfig\Output\absvti2_test.c.tmp
# executed command: C:/src/llvm-project/build.123/./bin/clang.exe -gline-tables-only -gcodeview -gcolumn-info -target i386-pc-windows-msvc -fno-builtin -I 'C:/src/llvm-project/compiler-rt\lib\builtins' -nodefaultlibs 'C:\src\llvm-project\compiler-rt\test\builtins\Unit\absvti2_test.c' 'C:/src/llvm-project/build.123/./lib/../lib/clang/23/lib/windows\clang_rt.builtins-i386.lib' -o 'C:\src\llvm-project\build.123\runtimes\runtimes-i386-pc-windows-msvc-bins\compiler-rt\test\builtins\Unit\I386WindowsConfig\Output\absvti2_test.c.tmp'
# .---command stdout------------
# | absvti2_test-e87f24.o : error LNK2019: unresolved external symbol ___acrt_iob_func referenced in function _printf
# | absvti2_test-e87f24.o : error LNK2019: unresolved external symbol ___stdio_common_vsprintf referenced in function __vsnprintf_l
# | absvti2_test-e87f24.o : error LNK2019: unresolved external symbol ___stdio_common_vfprintf referenced in function __vfprintf_l
# | LINK : error LNK2001: unresolved external symbol _mainCRTStartup
# | C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.29.30133\lib\x64\libcmt.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'x86'
# | C:\src\llvm-project\build.123\runtimes\runtimes-i386-pc-windows-msvc-bins\compiler-rt\test\builtins\Unit\I386WindowsConfig\Output\absvti2_test.c.tmp : fatal error LNK1120: 4 unresolved externals
# `-----------------------------
# .---command stderr------------
# | clang: error: linker command failed with exit code 1120 (use -v to see invocation)
# `-----------------------------
# error: command failed with exit status: 0x460

--

[ndrewh]

Ok. I think this is a step in the right direction, since we actually invoke clang with the correct target triple now (-target i386-pc-windows-msvc).

Unfortunately, I don't have any knowledge of MSVC or windows at all -- from afar, it looks like something picked the 64-bit libcmt \14.29.30133\lib\x64\libcmt.lib when it should have picked the 32-bit one due to the target triple. But -nodefaultlibs is also passed, so I don't know why any library is being linked at all.

If I had to guess, we could fix this by passing -m32 like the non-COMPILER_RT_DEFAULT_TARGET_ONLY path does for i386. But I'm really just guessing and I've never touched MSVC in my life.

I think this change as-is probably still fixes a real issue when testing builtins built with an explicit i386 triple on linux, so we should probably take it.

[ndrewh]

This could be worth a try (in place of the line changed by this PR)? We could at least confirm if we actually need -m32 in addition to -target. @zmodem

      if("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "i[2-6]86")
        set(TARGET_${COMPILER_RT_DEFAULT_TARGET_ARCH}_CFLAGS -target ${COMPILER_RT_DEFAULT_TARGET_TRIPLE} -m32)
      else()
        set(TARGET_${COMPILER_RT_DEFAULT_TARGET_ARCH}_CFLAGS -target ${COMPILER_RT_DEFAULT_TARGET_TRIPLE})
      endif()

It's kindof ugly, though.

[zmodem]

it looks like something picked the 64-bit libcmt

Yes, it's doing this based on environment variables. The overall build is targeting x86_64 windows, with the LIB environment variable pointing to the 64-bit runtime library.

But -nodefaultlibs is also passed, so I don't know why any library is being linked at all.

It's failing when building the test, compiler-rt/test/builtins/Unit/absvsi2_test.c, which has a main(), uses printf() etc. which is why it's trying to link the standard library.

If I had to guess, we could fix this by passing -m32

Sadly that doesn't help (I also tried your suggestion below). IIRC it doesn't have any deeper effect than changing the target triple to 32-bit.

Maybe the best fix for now would be to not try to run the 32-bit tests in 64-bit builds and vice versa.

[ndrewh]

@zmodem Are you building/testing any other compiler-rt components here? If you really can't link simple test programs, that shouldn't be a builtins-specific issue (Any other compiler-rt test should fail -- if they pass, then we should figure out what they are doing and copy it). I think you should probably just set -DRUNTIMES_i386-pc-windows-msvc_COMPILER_RT_INCLUDE_TESTS=OFF if your environment can't link simple i386 programs.