Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 22 Jun 2022 08:47:22 -0500 | Subject | Re: mainline build failure due to 281d0c962752 ("fortify: Add Clang support") |
| |
On Wed, Jun 22, 2022 at 5:23 AM Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote: > > I have recently (since yesterday) started building the mainline kernel > with clang-14 and I am seeing a build failure with allmodconfig.
Yeah, the clang build has never been allmodconfig-clean, although I think it's starting to get pretty close.
I build the kernel I actually _use_ with clang, and make sure it's clean in sane configurations, but my full allmodconfig build I do with gcc.
Partly because of that "the clang build hasn't quite gotten there yet" and partly because last I tried it was even slower to build (not a big issue for my default config, but does matter for the allmodconfig build, even on my beefy home machine)
I would love for people to start doing allmodconfig builds with clang too, but it would require some initial work to fix it... Hint, hint.
And in the case of this warning attribute case, the clang error messages are
(a) verbose
(b) useless
because they point to where the warning attribute is (I know where it is), but don't point to where it's actually triggering (ie where it was actually inlined and called from).
The gcc equivalent of that warning actually says exactly where the problem is. The clang one is useless, which is probably part of why people aren't fixing them, because even if they would want to, they just give up.
Nick, Nathan, any chance of getting better error messages out of clang? In some cases, they are very good, so it's not like clang does bad error messages by default. But in this case, the error message really is *entirely* useless.
Linus
| |