Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210714200523.GA10606@embeddedor>
In-Reply-To: <20210714200523.GA10606@embeddedor>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu, 15 Jul 2021 18:04:15 -0700
Message-ID: <CAHk-=wjQeeUiv+P_4cZfCy-hY13yGqCGS-scKGhuJ-SAzz2doA@mail.gmail.com>
Subject: Re: [GIT PULL] fallthrough fixes for Clang for 5.14-rc2
To:     "Gustavo A. R. Silva" <gustavoars@kernel.org>,
        Nathan Chancellor <nathan@kernel.org>,
        Nick Desaulniers <ndesaulniers@google.com>
Cc:     Kees Cook <keescook@chromium.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        clang-built-linux <clang-built-linux@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Jul 14, 2021 at 1:03 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git tags/Wimplicit-fallthrough-clang-5.14-rc2

Grr.

I merged this, but when I actually tested it on my clang build, it
turns out that the clang "-Wimplicit-fallthrough" flag is unbelievable
garbage.

I get

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

and the stupid warning doesn't even say WHERE THE PROBLEM HAPPENS.

No file name, no line numbers. Just this pointless garbage warning.

Honestly, how does a compiler even do something that broken? Am I
supposed to use my sixth sense to guide me in finding the warning?

I like the concept of the fallthrough warning, but it looks like the
clang implementation of it is so unbelievably broken that it's getting
disabled again.

Yeah, I can

 (a) build the kernel without any parallelism

 (b) use ">&" to get both output and errors into the same file

 (c) see that it says

    CC      kernel/sched/core.o
  warning: fallthrough annotation in unreachable code [-Wimplicit-fallthrough]
  1 warning generated.

and now I see at least which _file_ it is that causes that warning.

I can then use my incredible powers of deduction (it's almost like a
sixth sense, but helped by the fact that there's only one single
"fallthrough" statement in that file) to figure out that it's
triggered by this code:

                case cpuset:
                        if (IS_ENABLED(CONFIG_CPUSETS)) {
                                cpuset_cpus_allowed_fallback(p);
                                state = possible;
                                break;
                        }
                        fallthrough;
                case possible:

and it all makes it clear that the clang warning is just incredibly
broken garbage not only in that lack of filename and line number, but
just in general.

Yeah, I'm a bit pissed off at this. This clang warning really is
WRONG. It's so wrong in so many ways that I don't know what to say.

Except "yeah, that broken option is getting reverted again, because
the clang people messed up completely".

It's sad to see that people wasted time and effort on trying to make
clang happy, when it turns out that clang just gets this so _totally_
wrong.

                     Linus