Jeff Law wrote: > I'd respectfully disagree. There are certain features that GCC supports that Clang does not > and vice-versa. But broadly they are comparable. What this means is some projects that are > using bleeding edge features may have a hard need for one toolchain or the other. And the > proposal I've made accounts for that by allowing the upstream project to select the compiler. > In your case it would be GCC. For others it could well be Clang/LLVM. I respectfully disagree with your definition of bleeding edge ... IEEE-754-2008 (defined both Float128 and Decimal32/64/128. C11 includes the above in annex F. It seems like so long ago ;) Last I checked this is 2020 and GCC/GLIBC has made good progress implementing these standards. GCC supports several platforms (including PPC64LE) with hardware implementations for both types. The hard work has been done and Clang can leverage the run-time and standard headers directly. And while you allow that some packages have good reasons to stick with GCC. Several others on this list have demanded that clang/LLVM replace GCC as the default compiler. I respectfully restate my position that clang/LLVM is incomplete and not ready for that role. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
