[compiler-rt] Found one more delta to unbreak build for z/os (PR #82789)
Rainer Orth via llvm-commits
llvm-commits at lists.llvm.org
Thu Jan 30 07:31:04 PST 2025
================
@@ -756,8 +756,15 @@ set(riscv64_SOURCES
${riscv_SOURCES}
)
-set(sparc_SOURCES ${GENERIC_SOURCES} ${GENERIC_TF_SOURCES})
-set(sparcv9_SOURCES ${GENERIC_SOURCES} ${GENERIC_TF_SOURCES})
+# Exclude the FT sources for 32-bit SPARC. Clang doesn't
+# support 128-bit long double on 32-bit SPARC.
+if("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "sparc")
+ set(sparc_SOURCES ${GENERIC_SOURCES})
+ set(sparcv9_SOURCES ${GENERIC_SOURCES})
+else()
+ set(sparc_SOURCES ${GENERIC_SOURCES} ${GENERIC_TF_SOURCES})
+ set(sparcv9_SOURCES ${GENERIC_SOURCES} ${GENERIC_TF_SOURCES})
+endif()
----------------
rorth wrote:
I've meanwhile tried 2-stage builds on both `sparcv9-sun-solaris2.11` and `sparc64-unknown-linux-gnu`, each starting from `gcc-14` and `clang-19`. There were no failures.
However, the above is as wrong as it can get: on both Solaris/sparcv9 and Linux/sparc64 there were no `TF` files
compiled any longer, neither `sparc` nor `sparcv9`. For one, AFAICS `MATCHES` isn't anchored, so it matches all of `sparc`, `sparcv9`, and
`sparc64`. Besides, the concrete default SPARC target arch is completely irrelevant here: both a 64-bit-default compiler and a
32-bit-default compiler can produce both 32 and 64-bit objects.
https://github.com/llvm/llvm-project/pull/82789
More information about the llvm-commits
mailing list