[llvm-branch-commits] [compiler-rt] release/19.x: [builtins] Fix divtc3.c etc. compilation on Solaris/SPARC with gcc (#101662) (PR #101847)

[Sean Perry via llvm-branch-commits]

perry-ca wrote:

I have concerns about this change just thinking about this from the Solaris point of view.  A couple questions:
- from what I've learnt from Rainer, the Sparc 32-bit mode doesn't support long double.  In that case they should change the CMakefile file so none of the TF functions are compiled.
- why are you compiling the multc3 function and not the divtc3?  I would expect that if the compiler can generate one, it would be able to generate the other.

> It's difficult: on one hand it fixes a Solaris/SPARC build failure. On the other, it's said to cause problems for an out-of-tree z/OS port. Unfortunately, the developers refuse to publish their code, so it's almost impossible to reason about that code.

I take exception to the statement "the developers refuse to publish".  The z/OS code is in the process of being published.  No one has refused to publish code and we have worked with other contributors to compiler-rt to ensure the code builds on all platforms while we get the z/OS changes upstreamed.  This change will need to be undone and a proper fix applied for Sparc when we enable the z/OS buildbots.  I have asked @rorth to review #82789 and provide any changes required for Sparc.  I haven't heard back yet.

For z/OS, I am ok with this change in the 19.x release since we only depend on trunk and 18.x.  We do need to find a proper solution for Sparc in trunk.

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