-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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. > > > > > ... > > > > 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org - -- Igor Raits <ignatenkobr...@fedoraproject.org> -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aol8ACgkQEV1auJxc Hh5p+w//XQ32GF4YUnJUXbzQzquqogtmnr+wPcfsY9ZsjTR2PRQUhq+C0JV2ipf3 esitrJQlLPsBfU1pyxRT3ISFQZp4/RR6OtUddMPGS0TDj1UMyyBfuuRC+LKpm4wV MoYsOByMlKEZxeqHe2fKvWvxtcXhe1ocFaqpA3lJAPIxAg3UhjiZzqW7UjqqWQVI wC/Ap5BPSyNUH1QAtkfC98q58YNkMtm3YzUGHfebpp608gNgUzk/R8iE/Is+pHC0 laqiGpnhj8y2jwjqkBSc2sZhgwqYOYYPYy61YhouyNLNin5PqDA1dSBcnrNFXmHv gai1a9uHvN/jYUfDmpgE8TaO4EvWIncnlQV7E7SuH8X48nXNzYjqZl1CRj3bkAm6 kE/ZASmTE9p9aNrq5c7YnQy16zgX/jFVZuge4yKvJFfCZSSwMOPizVAMS2eVjBUG ToJE7q2YmGIwwqjX4W59HElCQXTwK4Yrscr5j9F5mJH+IOzOXuu3tW+XyeX6cjs6 OnyeXGJ1lojO5jBIC6PPJ5KtSFUBjOFyQqJb8ydYGdtwFXgjGDYxiBwJEASo00yE Gx1wpkIhQYGdglbDhVk8qd01S4c2IVpsb0ezGL2Irr0TKAtkFw9N6KM04hNf6zyH RdfTNrdJvNwR2QfyOdhWIRsdjI8/EnacZzORKOQ1pouldEuHQv4= =shcY -----END PGP SIGNATURE----- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
