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 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
