On Fri, Jul 10, 2020 at 03:31:00PM -0700, Linus Torvalds wrote: > On Fri, Jul 10, 2020 at 11:43 AM Nick Desaulniers > <ndesaulni...@google.com> wrote: > > > > What I'd really like to see as a policy in the kernel going forward in > > that ANY new commit that adds some hack or workaround for a specific > > compiler version add a comment about which toolchain version was > > problematic, that way when we drop support for that version years > > later, we can drop whatever hacks and technical debt we've accumulated > > to support that older version. > > The problem is that at the time we find and fix things, it's often > _very_ unclear which compiler versions are affected. > > We also have the situation that a lot of distro compilers aren't > necessarily completely "clean" versions, particularly for the > "enterprise" ones that get stuck on some old version and then fix up > their breakage by backporting fixes.
Indeed. I would say this is less common for most distributions with clang, where they tend to stick closer to tip of tree, but it can still happen. I guess there is not a really good solution for this but we could just have a policy that as soon as you move away from the upstream version, you are on your own. > When it's some particular version of a compiler that supports a > particular feature, that tends to be much more straightforward. But > we've had bugs where it was very unclear when exactly the bug was > fixed (fi it was fixed at all by the time we do the workaround). As for putting a seal of approval on a minimum supported version of LLVM/clang, I have my reservations. 0day keeps uncovering various issues with its builds and clang's release model is different than from GCC's so if we ever come across a compiler bug in an older version of clang, we have basically no hope for getting it fixed. GCC supports older series through bug fix releases for quite some time (GCC 7 was supported for two and a half years), whereas with clang, they only see one servicing release before the next major release (for example, clang 9.0.1 before clang 10.0.0) so it makes getting compiler fixes into the hands of users much more difficult. I am trying to rectify that with clang 10 though, where I have been testing that release against a bunch of different configs both in tree and out of tree: https://github.com/nathanchance/llvm-kernel-testing However, I think at this point, we can say clang itself is in a good position as of clang 9, certainly clang 10. I am less confident in placing a minimum version on the LLVM tools such as lld though. For arm, arm64, and x86_64, we are in fairly good shape as of clang 10 but I think there is probably some more work/polishing to be done there; for other architectures, it is worse. I suppose we would have to consider the support model: under what cases is it acceptable to bump the minimum required version versus inserting a bad compiler hack? As someone who is not super familiar with the relationship between GCC and the kernel, it appears to me that the general attitude towards compiler bugs has been workaround it in the kernel while hoping that it gets fixed at some point in GCC. We have been pretty aggressive about fixing the compiler instead of inserting a workaround, which I feel like is the better solution, but it makes supporting multiple versions of the compiler more difficult (versus just saying use the latest). It is something that needs to be discussed and agreed upon sooner rather than later though, especially as we grow more and more polished. There were some other thoughts that I had on our issue tracker here, if anyone cares for them: https://github.com/ClangBuiltLinux/linux/issues/941 Sorry for the brain dump and cheers, Nathan
