On Fri, 2020-06-05 at 21:51 +0200, Igor Raits wrote: > On Fri, 2020-06-05 at 13:36 -0600, Jeff Law wrote: > > > 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. > > Sure thing! I just asked to have it documented that as of F33 it is not > yet implemented, but is planned to be worked on. So that users do not > expect it to have all security features built-in as on F33. Where do we want this documented? I don't mind adding verbage to the change proposal around this, but I fear that's really not the right place and the info will get lost. Perhaps make it part of the packaging guidelines change if/when we make a change? 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
