Message-ID: <CAK8P3a3o_r6z25Sm5iceWTo4OopiKP8MdBSvSctRvtUp4UFaCQ@mail.gmail.com>
Date:   Mon, 24 Apr 2017 16:13:46 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     "Maciej W. Rozycki" <macro@...ux-mips.org>,
        Kees Cook <keescook@...omium.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        linux-kbuild <linux-kbuild@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Russell King <rmk+kernel@...linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>,
        kernel-build-reports@...ts.linaro.org, kvmarm@...ts.cs.columbia.edu
Subject: Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

On Mon, Apr 24, 2017 at 12:17 PM, Geert Uytterhoeven
<geert@...ux-m68k.org> wrote:
> On Mon, Apr 24, 2017 at 11:44 AM, Arnd Bergmann <arnd@...db.de> wrote:
>> On Sun, Apr 23, 2017 at 10:13 PM, Geert Uytterhoeven
>> <geert@...ux-m68k.org> wrote:
>>> On Sat, Apr 22, 2017 at 5:30 PM, Arnd Bergmann <arnd@...db.de> wrote:
>>> My main motivation for keep on using gcc-4.1 is that it gives many warnings
>>> that were disabled in later gcc versions.  I do look at all new warnings, and
>>> send patches when they are real bugs, or are trivial to silence.
>>
>> What kind of warnings do you see that disappeared with later versions?
>> Do you know what caused them to disappear in later versions (different
>> optimization decisions, warning getting disabled by default but still available
>> for turning on manually, ...)? Do you know if the disabled warnings are
>> still there in gcc-4.3 (I can try it out if you give me examples)?
>
> Mostly the "may be used uninitialized" warnings. I believe they were disabled
> in gcc-4.3 (4.2?) and later due to too many false positives, which is not an
> issue for me, as I look at differences.
> They were re-enabled lately (with much less false-positives), that's why you
> see them, and fix them.

Linus added -Wno-maybe-uninitialized a while ago, and I think only gcc-4.8
and higher were affected by that, as earlier versions only understand
-Wuninitialized (meaning both "definitely uninitialized" and "might be
uninitialized". The latest state is that gcc-4.9 enables all uninitialized
warnings and I try to fix them for all known compilers, gcc-4.8
disables -Wmaybe-uninitialized unless you build with "make W=2".

On gcc-4.9 and higher, we also don't enable -Wmaybe-unintialized when
certain configuration options are set that cause extra false positives,
but it's still enabled with W=2.

I actually think it would be a good idea to also disable -Wuninitialized
for gcc-4.7 and earlier unless you ask for W2. That would get us
much closer to a clean build, but still give you the chance to see the
warnings if you really want to.

> For example, do you see the warning fixed by commit 1b8c1012142d8322
> ("drivers: net: xgene: Simplify xgene_enet_setup_mss() to kill warning")
> with gcc-4.3? Yes, that was a false positive.

I see this one until gcc-4.8 if I build with W=2 to turn the warning back on.

> Or see commit cc4a7ffe02c95f53 ("spi: fsl-lpspi: Pre-initialize ret in
> fsl_lpspi_transfer_one_msg()"). That one was a real bug.
>
> I don't see that in any of the kisskb build logs, and they use gcc-4.2.4 for
> avr32. So having gcc-4.2 or gcc-4.3 in a farm won't help.

Also here: I see the warning on ARM with all versions from gcc-4.1 through
4.8 (with W=1), but not any higher versions including 7.0.1. If I mark
fsl_lpspi_transfer_one as 'noinline', I see it on all versions, which is a bit
odd. It might be worth opening a gcc bug report for that. I tried the
'noinline' as I suspected gcc might be smart enough to figure out that
the list is never empty, but I later noticed that it has no way of knowing
that even without the 'noinline' flag.

> And as long as I find real bugs this way, I'd like to continue doing it.

I've tested all the architectures I mentioned earlier that were around 10
years ago (aside from ia64, I could not build gcc successfully) with
linux-4.3 (arbitrarily picked, this was the version in which x86 and mips
no longer built with gcc-4.1), and built a defconfig with both gcc-4.9
(which I had around from earlier testing) and with gcc-4.1/4.3:

          gcc-4.1  gcc-4.3  gcc-4.9
alpha  failed    success success
arm    failed     success success
cris     failed     success success
frv       failed     failed    success
m32r  success success success
m68k  success success success
mips   failed     failed     success
parisc success success success
powerpc failed failed    success
s390    failed    failed    success
sh        failed    success success
x86      failed    success success

I'd conclude that nobody aside from you sends bugfixes for 4.1,
or has done so in a while. I have the logs available if you want,
but there isn't really much surprising: we get the same link error
as on mips and x86 on some additional architectures, powerpc
and s390 use features that weren't available and frv hits an ICE.

We could define the minimum compiler to be gcc-4.3 on all architectures
except m68k (and possibly parisc, certainly nobody cares about
m32r enough), where it would be gcc-4.1, to reflect what is actually
already the case.

        Arnd

Powered by blists - more mailing lists