On Tue, Jul 23, 2019 at 1:22 PM Nathan Chancellor <[email protected]> wrote: > > On Tue, Jul 23, 2019 at 01:03:05PM +0200, Arnd Bergmann wrote: > > On Tue, Jul 23, 2019 at 12:50 PM Peter Zijlstra <[email protected]> > > wrote: > > > On Fri, Jul 19, 2019 at 01:36:00PM +0200, Arnd Bergmann wrote: > > > > --- a/include/linux/wait.h > > > > +++ b/include/linux/wait.h > > > > @@ -70,8 +70,17 @@ extern void __init_waitqueue_head(struct > > > > wait_queue_head *wq_head, const char *n > > > > #ifdef CONFIG_LOCKDEP > > > > # define __WAIT_QUEUE_HEAD_INIT_ONSTACK(name) \ > > > > ({ init_waitqueue_head(&name); name; }) > > > > -# define DECLARE_WAIT_QUEUE_HEAD_ONSTACK(name) \ > > > > +# if defined(__clang__) && __clang_major__ <= 9 > > > > +/* work around https://bugs.llvm.org/show_bug.cgi?id=42604 */ > > > > +# define DECLARE_WAIT_QUEUE_HEAD_ONSTACK(name) > > > > \ > > > > + _Pragma("clang diagnostic push") > > > > \ > > > > + _Pragma("clang diagnostic ignored \"-Wuninitialized\"") > > > > \ > > > > + struct wait_queue_head name = > > > > __WAIT_QUEUE_HEAD_INIT_ONSTACK(name) \ > > > > + _Pragma("clang diagnostic pop") > > > > +# else > > > > +# define DECLARE_WAIT_QUEUE_HEAD_ONSTACK(name) \ > > > > struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name) > > > > +# endif > > > > > > While this is indeed much better than before; do we really want to do > > > this? That is, since clang-9 release will not need this, we're basically > > > doing the above for pre-release compilers only. > > > > Kernelci currently builds arch/arm and arch/arm64 kernels with clang-8, > > and probably won't change to clang-9 until after that is released, > > presumably in September. > > > > Anyone doing x86 builds would use a clang-9 snapshot today > > because of the asm-goto support, but so far the fix has not > > been merged there either. I think the chances of it getting > > fixed before the release are fairly good, but I don't know how > > long it will actually take. > > > > Arnd > > Furthermore, while x86 will only be supported by clang-9 and up, there > are other architectures/configurations that work with earlier versions > that will never see that fix. There are a few people that still use > clang-7 for example. > > In an ideal world, everyone should be using the latest version of clang > because of all of the fixes and improvements that are going into that > latest version but the same can be said of any piece of software. I am > not sure that it is fair to force someone to upgrade when it works for > them. Not everyone runs Ubuntu/Debian to get access to apt.llvm.org > builds or wants to add random repositories to their list or wants to > build clang from source. > > I suppose it comes down to policy: if we don't want to support versions > of LLVM before 9.x then we should just break the build when it is > detected but Nick has spoken out against that and I think that he has a > fair point. > > https://lore.kernel.org/lkml/CAKwvOdnzrMOCo4RRsfcR=k5elwu8obgmqtogznx_avlrarj...@mail.gmail.com/
Note that pre-clang-9 can be used for LTS x86_64; I don't think CONFIG_JUMP_LABEL was made mandatory for x86 until 4.20 release, IIRC. There's only a small window of non LTS kernels and only for x86 where clang-9+ is really necessary. Thanks, ~Nick Desaulniers
