lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sun, 14 Nov 2021 18:07:56 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Gustavo A. R. Silva" <gustavoars@...nel.org>
Cc:     Nathan Chancellor <nathan@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-hardening@...r.kernel.org
Subject: Re: [PATCH] kbuild: Fix -Wimplicit-fallthrough=5 error for GCC 5.x
 and 6.x

On Sun, Nov 14, 2021 at 5:08 PM Gustavo A. R. Silva
<gustavoars@...nel.org> wrote:
>
> -Wimplicit-fallthrough=5 was under cc-option because it was only
> available in GCC 7.x and newer so the build is now broken for GCC 5.x
> and 6.x:

Annoying. And I obviously never saw it because I don't carry ancient
compiler versions.

That said:

> -       default "-Wimplicit-fallthrough=5" if CC_IS_GCC
> +       default "-Wimplicit-fallthrough=5" if $(cc-option,-Wimplicit-fallthrough=5)

I think it would be better to keep the CC_IS_GCC part of the test, for
the simple reason that the clang "make config" is already very slow.

I'm not sure why, but it's annoyingly noticeable, and I've complained
about clang performance before in this area (and the likely cause is
the default build for clang being this horribly inefficient shared
library setup, so it spends ages just doing dynamic linking)

Whenever I do "make oldconfig" with a clang build, and my machine is
under any reasonable load (typically because I'm also doing another
build in another terminal at the same time), it takes several seconds.

Doing the same thing with gcc is noticeably much faster.

In fact, it doesn't even need to be a very loaded machine, this is
basically an empty "re-do config" with gcc vs clang (basically same
config, except obviously for compiler-induced config differences):

  gcc$ time make oldconfig
  real 0m0.929s

  clang$ time make oldconfig
  real 0m1.917s

Two seconds may not seem like a lot, but when the machine is under my
usual build load, that almost 2s easily becomes a "do I need to go for
coffee" delay, since I'm just waiting for the config to finish before
I start the build (since I may end up having to answer questions).

And yeah, it's sad how much faster gcc is.

There was a time when the clang people were proud of their
compile-time performance. Pepperidge farm remembers.

Anyway, I'd prefer to not ask for the clang build to do even more
work, since we know it will fail that '=5' case.

             Linus

Powered by blists - more mailing lists