Finn Thain
2020-Nov-25 21:33 UTC
[Nouveau] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
On Wed, 25 Nov 2020, Nick Desaulniers wrote:> So developers and distributions using Clang can't have > -Wimplicit-fallthrough enabled because GCC is less strict (which has > been shown in this thread to lead to bugs)? We'd like to have nice > things too, you know. >Apparently the GCC developers don't want you to have "nice things" either. Do you think that the kernel should drop gcc in favour of clang? Or do you think that a codebase can somehow satisfy multiple checkers and their divergent interpretations of the language spec?> This is not a shiny new warning; it's already on for GCC and has existed > in both compilers for multiple releases. >Perhaps you're referring to the compiler feature that lead to the ill-fated, tree-wide /* fallthrough */ patch series. When the ink dries on the C23 language spec and the implementations figure out how to interpret it then sure, enforce the warning for new code -- the cost/benefit analysis is straight forward. However, the case for patching existing mature code is another story.
Nick Desaulniers
2020-Nov-25 22:09 UTC
[Nouveau] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
On Wed, Nov 25, 2020 at 1:33 PM Finn Thain <fthain at telegraphics.com.au> wrote:> > Or do you think that a codebase can somehow satisfy multiple checkers and > their divergent interpretations of the language spec?Have we found any cases yet that are divergent? I don't think so. It sounds to me like GCC's cases it warns for is a subset of Clang's. Having additional coverage with Clang then should ensure coverage for both.> > This is not a shiny new warning; it's already on for GCC and has existed > > in both compilers for multiple releases. > > > > Perhaps you're referring to the compiler feature that lead to the > ill-fated, tree-wide /* fallthrough */ patch series. > > When the ink dries on the C23 language spec and the implementations figure > out how to interpret it then sure, enforce the warning for new code -- the > cost/benefit analysis is straight forward. However, the case for patching > existing mature code is another story.I don't think we need to wait for the ink to dry on the C23 language spec to understand that implicit fallthrough is an obvious defect of the C language. While the kernel is a mature codebase, it's not immune to bugs. And its maturity has yet to slow its rapid pace of development. -- Thanks, ~Nick Desaulniers
Finn Thain
2020-Nov-25 23:21 UTC
[Nouveau] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
On Wed, 25 Nov 2020, Nick Desaulniers wrote:> On Wed, Nov 25, 2020 at 1:33 PM Finn Thain <fthain at telegraphics.com.au> > wrote: > > > > Or do you think that a codebase can somehow satisfy multiple checkers > > and their divergent interpretations of the language spec? > > Have we found any cases yet that are divergent? I don't think so.There are many implementations, so I think you are guaranteed to find more divergence if you look. That's because the spec is full of language like this: "implementations are encouraged not to emit a diagnostic" and "implementations are encouraged to issue a diagnostic". Some implementations will decide to not emit (under the premise that vast amounts of existing code would have to get patched until the compiler goes quiet) whereas other implementations will decide to emit (under the premise that the author is doing the checking and not the janitor or the packager).> It sounds to me like GCC's cases it warns for is a subset of Clang's. > Having additional coverage with Clang then should ensure coverage for > both. >If that claim were true, the solution would be simple. (It's not.) For the benefit of projects that enable -Werror and projects that nominated gcc as their preferred compiler, clang would simply need a flag to enable conformance with gcc by suppressing those additional warnings that clang would normally produce. This simple solution is, of course, completely unworkable, since it would force clang to copy some portion of gcc's logic (rewritten under LLVM's unique license) and then to track future changes to that portion of gcc indefinitely.
Finn Thain
2020-Nov-26 00:30 UTC
[Nouveau] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
On Wed, 25 Nov 2020, Nick Desaulniers wrote:> On Wed, Nov 25, 2020 at 1:33 PM Finn Thain <fthain at telegraphics.com.au> wrote: > > > > Or do you think that a codebase can somehow satisfy multiple checkers > > and their divergent interpretations of the language spec? > > Have we found any cases yet that are divergent? I don't think so.You mean, aside from -Wimplicit-fallthrough? I'm glad you asked. How about -Wincompatible-pointer-types and -Wframe-larger-than? All of the following files have been affected by divergent diagnostics produced by clang and gcc. arch/arm64/include/asm/neon-intrinsics.h arch/powerpc/xmon/Makefile drivers/gpu/drm/i915/Makefile drivers/gpu/drm/i915/i915_utils.h drivers/staging/media/atomisp/pci/atomisp_subdev.c fs/ext4/super.c include/trace/events/qla.h net/mac80211/rate.c tools/lib/string.c tools/perf/util/setup.py tools/scripts/Makefile.include And if I searched for 'smatch' or 'coverity' instead of 'clang' I'd probably find more divergence. Here are some of the relevant commits. 0738c8b5915c7eaf1e6007b441008e8f3b460443 9c87156cce5a63735d1218f0096a65c50a7a32aa babaab2f473817f173a2d08e410c25abf5ed0f6b 065e5e559555e2f100bc95792a8ef1b609bbe130 93f56de259376d7e4fff2b2d104082e1fa66e237 6c4798d3f08b81c2c52936b10e0fa872590c96ae b7a313d84e853049062011d78cb04b6decd12f5c 093b75ef5995ea35d7f6bdb6c7b32a42a1999813 And before you object, "but -Wconstant-logical-operand is a clang-only warning! it can't be divergent with gcc!", consider that the special cases added to deal with clang-only warnings have to be removed when gcc catches up, which is more churn. Now multiply that by the number of checkers you care about.