lkml.org 
[lkml]   [2022]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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

\
 
 \ /
  Last update: 2022-06-22 15:49    [W:0.123 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site