Re: [GIT PULL] fallthrough fixes for Clang for 5.14-rc2

Gustavo A. R. Silva
2021-07-16T01:27:03Z

On 7/15/21 20:22, Linus Torvalds wrote:
> On Thu, Jul 15, 2021 at 6:14 PM Gustavo A. R. Silva
> <gustavo@embeddedor.com> wrote:
>>
>> Kees just opened a bug report for this:
>>
>> https://bugs.llvm.org/show_bug.cgi?id=51094
>
> I don't have an account on that bugzilla, but it might be worth adding
> the note that no warning or error should EVER not say where it
> happens.

Yeah; I'll add that to the report.

Here is the current description of the bug:

"There are some places in the kernel where the "fallthrough;" annotation is used after a portion of code that may get elided at build time:

case 1:
if (something || !IS_ENALBED(CONFIG_SOMETHING))
return blah;
fallthrough;
case 2:
This looks like:

case 1:
fallthrough;
case 2:
And a warning is generated:

warning: fallthrough annotation in unreachable code [-Wimplicit-fallthrough]

But isn't a useful warning in this case, and should likely be silenced or adjust to not warn where there was actually code there before getting elided. At the
least, this warning would be best moved to a separate flag so it can be disabled on kernel builds (i.e. GCC does not warn about these cases).

Some specific examples:

https://github.com/ClangBuiltLinux/continuous-integration2/runs/3058126539?check_suite_focus=true#step:5:120
https://github.com/ClangBuiltLinux/continuous-integration2/runs/3058126329?check_suite_focus=true#step:5:92
"

> That's the thing that made me pissed off in the first place. I build
> my kernels with "make -j128", and if the warning doesn't specify the
> filename and the line number, the warning is just unacceptably bad.
>
> How can a compiler _ever_ give a warning without specifying where it is?
>
> The fact that the warning is also entirely wrong-headed in the first
> place is just the extra cherry on top.
>
> But at least it should hopefully make it easy to fix in clang - just
> remove the incredibly broken thing entirely.
>
> Linus
>

--
Gustavo