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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a1aef+rqxtfj5CJr_roZHysUAm3p9BHMTQO9OvtNhGJcg@mail.gmail.com>
Date:   Thu, 21 Feb 2019 14:16:13 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nathan Chancellor <natechancellor@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH] kbuild: compute false-positive -Wmaybe-uninitialized
 cases in Kconfig

On Thu, Feb 21, 2019 at 10:45 AM Masahiro Yamada
<yamada.masahiro@...ionext.com> wrote:
> On Thu, Feb 21, 2019 at 6:23 PM Arnd Bergmann <arnd@...db.de> wrote:
> > On Thu, Feb 21, 2019 at 5:14 AM Masahiro Yamada
> > <yamada.masahiro@...ionext.com> wrote:
> >
> > I like how this cleans up the logic and documents it better.
> > I've had my own plans to move this (and most other conditional warning
> > options) into a header file using the KBUILD_WARN() infrastructure, but
> > never got around to doing that. I still think that's what we want eventually,
> > but in the meantime your patch seems fine as well.
> >
> > Also, I see that your patch keeps the existing logic, which is good,
> > but we may want to refine this a little afterwards:
> >
> > - we may want to turn off -Wuninitialized for gcc-4.6 and gcc-4.7
> >   instead of turning off -Wmaybe-uninitialized as we do in the later
> >   compilers.
>
> Ah, right.
>
> I can do that if it is worthwhile.
>
> But, I'd rather want to raise the minimum compiler version
> than taking care of old compilers.
> (We will do it eventually.)

I was hoping that with gcc-4.6 being the minimum version, we could
actually get all supported compilers to produce clean builds on
all configurations, possibly at the cost of just turning off all
unreliable warning options on older compilers.

I don't mind regularly raising the minimum version, but I would
also wait several years before I'd consider gcc-4.9 a good
choice for the minimum, and all older versions have problems
here.

> Does clang recognize -Wmaybe-uninitialized?
>
> I am using Clang I built a few days ago.
>
>
> masahiro@pug:~$ clang --version
> clang version 9.0.0 (http://llvm.org/git/clang.git
> b492883ea31e2046d5725126318911465bc1374f)
> (http://llvm.org/git/llvm.git
> 03a15eec9ef44798cd5c57b4ed6a63e62b2c1db6)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir: /home/masahiro/toolchains/clang-latest/bin
>
> masahiro@pug:~$ clang -x c /dev/null  -Wmaybe-uninitialized -c -o  /dev/null
> warning: unknown warning option '-Wmaybe-uninitialized'; did you mean
>       '-Wuninitialized'? [-Wunknown-warning-option]
> 1 warning generated.

Ah, that's right. I also see -Wconditional-uninitialized and
-Wsometimes-uninitialized, but they are something different again.

       Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ