Message-ID: <CAHk-=wjah-fkfzMdmCNN8v7uriJsGeYjHh18wkXDZa2sxuAXzA@mail.gmail.com>
Date:   Sun, 10 May 2020 12:33:07 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Arnd Bergmann <arnd@...db.de>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: I disabled more compiler warnings..

Arnd, Masahiro, (anybody else?),
  I don't know how much you care - I thought at least Arnd might - but
I've upgraded my main desktop to gcc-10. I did that partly because a
bug report that initially seemed to blame the compiler, but eventually
turned out to be unrelated.

And as part of that, there were a lot of new warnings in the kernel build.

I let them go for a while, in the belief that I could deal with it,
but then yesterday I did a pull and didn't initially even notice that
the end result didn't compile for me, because the build error was
hidden by the hundreds of lines of warnings (not hundreds of warnings,
but gcc has gotten to be pretty verbose about the warnings, so each
warning was often 5+ lines of "this is where it happened, this is
where it was included from, and this is where the offending thing was
declared")

A lot of them were good warnings where gcc warns about things it
really should warn about - if you have modern source code and actually
use flexible arrays etc. Which we're moving towards, but we're not
there yet, and clearly won't be for 5.7.

So I don't think those parts are at all controversial. We'll get the
zero-sized arrays converted, and then we'll have another slew of
one-sized array declarations that will also have to be taken care of,
but I hope we can re-enable those array limit warnings in the not too
distant future. They should be fairly unambiguously a good thing once
we've sorted out the legacy code, which people are working on anyway.

Same to some degree goes for the 'restrict' warning, which we don't
need right now and triggers for what is a somewhat odd - but not
entirely unusual - case for the kernel. That warning right now has no
upside for us, but it's a potentially interesting warning for the
future. And the special 'free()' warning is gcc doing things the wrong
way, but that one was easy enough to just avoid in the first place,
without making the source code any worse.

So most of the warning removals are fairly innocuous:

   gcc-10: disable 'restrict' warning for now
   gcc-10: disable 'stringop-overflow' warning for now
   gcc-10: disable 'array-bounds' warning for now
   gcc-10: disable 'zero-length-bounds' warning for now

and two were fixes/cleanups to the kernel to avoid new warnings:

   gcc-10: mark more functions __init to avoid section mismatch warnings
   gcc-10: avoid shadowing standard library 'free()' in crypto

but the one commit I wanted to point out - because I think Arnd may
care - is me giving up on the "maybe initialized" warning once again.

This is the usual "gcc optimizations changed, now it can't follow the
flow of code it used to handle fine, and it warns in several new
places that are almost certainly false positives":

   Stop the ad-hoc games with -Wno-maybe-initialized

so now -Wno-maybe-uninitialized is the default behavior, and if you
want to see those (very unreliable) warnings, you need to use "W=2"
which has explicitly enabled it for a longish time.

I simply refuse to be in the situation where I might miss an
_important_ warning (or, like happened yesterday, an actual failure),
because the stupid warning noise is hiding things that matter. Yes, I
caught the build error despite the noise, but that was partly luck (I
did another pull before I pushed out, and caught the error on the
second build). And yes, I've made my workflow now hopefully make sure
that the actual build error will stand out more, but even hiding just
other - more real - warnings is a problem, so I do not want to see the
pointless noise.

But I wish there was a better model for handling those "maybe
uninitialzed" issues. Some of them _have_ been valid, even if a huge
amount are just the compiler not following the use of the variables
well enough.

So I thought I'd at least mention this thing, and see if people have
any sane solutions.

             Linus

Powered by blists - more mailing lists