[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