[compiler-rt] Found one more delta to unbreak build for z/os (PR #82789)

[Rainer Orth via llvm-commits]

================
@@ -383,10 +383,10 @@ static __inline fp_t __compiler_rt_fmax(fp_t x, fp_t y) {
 #endif
 }
 
-#elif defined(QUAD_PRECISION) && defined(CRT_HAS_TF_MODE)
+#elif defined(QUAD_PRECISION)
+#if defined(CRT_HAS_TF_MODE) && defined(CRT_HAS_IEEE_TF)
----------------
rorth wrote:

> So Clang and GCC disagree on the Linux ABI here? It sounds like clang should be following GCC and using 128-bit long double since that will be used for all existing Linux code?

No: Solaris/sparc follows the ELF SPARC psABI which dictates that `long double` be 128-bit. While Linux/sparc, generally following the psABI, it chose to ignore that particular part of the spec and went for 64-bit `long double` instead.  `clang` should indeed match the psABI/GCC/Solaris `libc`, but fixing this is way beyond my abilities, and LLVM SPARC maintenance these days is limited.

> If there is not 128-bit floating point type on sparc (at least with clang), the it sounds to me like it should not be building the _tf_ files at all?

There is on Solaris, but it's soft-float only.

> It looks like GCC uses IEEE 128-bit long double, so maybe we can just hoist the ifdefs above the `fp_lib.h` include?

I've meanwhile found that the `builtins` situation is even messier than I thought: until LLVM 17, `libclang_rt.builtins-sparc.a` **did** contain `__divtc3` and`__multc3`.  Sometime before LLVM 18, those definitions got lost (and apparently there are no checks that the `builtins` interface remains stable).  So instead of cementing that regression, the definitions should be restored, not removed for good.  I've started looking into when the removal happened, but unfortunately so many intermediate revisions don't even build that this is very hard to do ;-(

What I believe should happen first is identify the revision that caused this breakage, than look into fixing that to continue working on SPARC together with whatever it was meant to achieve.


https://github.com/llvm/llvm-project/pull/82789