> On Thu, 2020-06-04 at 16:30 -0400, Igor Raits wrote: > ... > > Sadly some upstreams insist on clang just because they like it more, > without any technical reason. The question that comes to my mind: > Should we still try to convince upstreams to use GCC in such cases or > not? It happens (choosing Clang because they like it) and while we can (and have) engaged upstreams on this topic and I suspect we will continue to do so in some cases. But in the end I think we still have to respect the upstream project's choices, even if it's just because they like Clang/LLVM more than GCC. > > Also does this mean that Clang is now fully supported compiler by full- > time working people @ Red Hat in toolchains team that are also > contributing to upstream? Just curious if we will be able to "fully > support" people when we find bugs in the compiler. Yes. Absolutely. Tom S & Serge G directly. Others in a more indirect capacity. > > And also, does it mean that we will be following same pattern as with > GCC to test pre-release versions in rawhide, do the mass rebuild and so > on? Some of that is already happening internally. Tom's got a tester which spins Fedora packages with Clang/LLVM. I'm not sure if he's trying to cover the whole distro, but it is running regularly (it shares a jenkins instance with my tester). > ... > > I think this is not fully true because clang / gcc produce different > binaries in terms of size / performance. So just switching compiler in > some package may result in significat (hopefully not) performance gain > / drop. Certainly switching compilers can result in performance changes. Having been through this kind of disruptive change on the other side (GCC vs various vendor compilers through the 90s), what tends to happen is the compilers get to a point where they're typically +-5% of each other on the vast majority of codes. That's where Clang/LLVM and GCC are today based on the data I've seen. > > Also we probably should mention that -fstack-clash-protection is not > available in clang, so in theory binaries can be less secure due to > that. Clang/LLVM is closing that gap rapidly. I fully expect stack clash protection to be at parity on the relevant platforms except aarch64 by LLVM 11 and a reasonable chance to reach parity on aarch64 by LLVM 12. > > ... > > I think this should mention that annobin plugin should be prepared for > clang. Nick Clifton is already working on that :-) Jeff _______________________________________________ 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
