From: Arnd Bergmann <arnd@arndb.de> To: Geert Uytterhoeven <geert@linux-m68k.org> Cc: linux-arch <linux-arch@vger.kernel.org>, Kees Cook <keescook@chromium.org>, linux-kbuild <linux-kbuild@vger.kernel.org>, kernel-build-reports@lists.linaro.org, LKML <linux-kernel@vger.kernel.org>, Russell King <rmk+kernel@armlinux.org.uk>, "Maciej W. Rozycki" <macro@linux-mips.org>, Andrew Morton <akpm@linux-foundation.org>, kvmarm@lists.cs.columbia.edu, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6? Date: Mon, 24 Apr 2017 11:44:26 +0200 [thread overview] Message-ID: <CAK8P3a32Y0AiKyVaotYb14uZZ1jM=nwhFD1vyP56epW1Y9KqSw@mail.gmail.com> (raw) In-Reply-To: <CAMuHMdWTiurUSacddYXgW69=QwOrZDV3Zt2DezJauPy8j-GMHw@mail.gmail.com> On Sun, Apr 23, 2017 at 10:13 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Arnd, > > On Sat, Apr 22, 2017 at 5:30 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> Based on what I found so far, gcc-4 can be pretty much ruled out from >> being the minimum version based on the number of failures I got. >> It's much better than 3.4 but much worse than 4.1 or 4.2 which seem >> fixable on MIPS and x86 at least, and may or may not work depending >> on configuration. So the best two possible (but conflicting) answers I >> have are >> >> a) There are known users on gcc-4.1, and we never break things that >> work for users, so gcc-4.1 (or possibly 4.0 if a user shows up) would >> be the minimum version. >> b) gcc-4.1 and 4.2 have too many problems, so users are better off >> when we tell them to upgrade to something newer, and a minimum >> version of gcc-4.3 has fewer surprises. We should remove all >> workarounds for pre-gcc-4.3 compilers and just force a build error >> message. > > If there's no real good reason (brokenness) to deprecate gcc-4.1, I would not > do it.I guess most people using old compilers know what they're doing. What I'm trying to find out first is whether "people regularly using 10+ year old compilers for the latest kernels" is a strict subset of "people in Geert's household". Given that none of the three architectures I looked at (arm, mips, x86) has successfully built any defconfig for a few years, it's quite possible that it's just you ;-) The other architectures that were around 10 years ago (so they might have someone who still has old toolchain binaries) and that still exist today are alpha, cris, frv, ia64, m32r, parisc, powerpc, s390, sh, sparc and xtensa. The first six are similar to m68k in that the hardware is mostly obsolete and the ports are kept around to support those old systems that might also use ancient toolchains, or new toolchains may be unmaintained or buggy, which could be a reason to keep 4.1 supported or at least try to find out if 4.1 (or even any other version) still works at all. > 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)? > Lately the usefulness has been decreasing, as you've been too aggressively > killing compiler warnings with recent gcc versions (which became better) ;-) > Hence if I detected a new warning with a point or an rc release, it usually > means the code was never in nex (ugh)t, or the maintainer ignored your patch. > > I could easily switch to v4.9 from kernel.org crosstool, though, but then I > would loose all those warnings. If gcc-4.3 produces similarly useful warnings, we could think about integrating gcc-4.3 into kernelci.org build reports as an option, and fix up all the existing warnings we get with that. I wouldn't want to do that with gcc-4.1 though as the older versions have relatively random behavior. One particular feature I'd like to use that requires a newer compiler is being able to control warnings per function liker glibc does, using e.g. '_Pragma("GCC diagnostic disable \"-Woverride-init\"")'. Once we have that, we could turn on a couple of additional warnings that are generally useful but also warn about code that intentionally does something that would trigger the warning. > BTW, below is the diff I use to avoid an ICE. > After that, it builds and (test)boots fine on ARAnyM ;-) I guess this means that even your builds require extra patches and you can't strictly build a defconfig and expect that to work ;-) Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de> To: Geert Uytterhoeven <geert@linux-m68k.org> Cc: "Maciej W. Rozycki" <macro@linux-mips.org>, Kees Cook <keescook@chromium.org>, linux-arch <linux-arch@vger.kernel.org>, linux-kbuild <linux-kbuild@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Russell King <rmk+kernel@armlinux.org.uk>, Andrew Morton <akpm@linux-foundation.org>, kernel-build-reports@lists.linaro.org, kvmarm@lists.cs.columbia.edu Subject: Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6? Date: Mon, 24 Apr 2017 11:44:26 +0200 [thread overview] Message-ID: <CAK8P3a32Y0AiKyVaotYb14uZZ1jM=nwhFD1vyP56epW1Y9KqSw@mail.gmail.com> (raw) Message-ID: <20170424094426.6icMfOpjxz45Pr8QMzLvGvcW1h55tOpc4hAhR6O9LJ4@z> (raw) In-Reply-To: <CAMuHMdWTiurUSacddYXgW69=QwOrZDV3Zt2DezJauPy8j-GMHw@mail.gmail.com> On Sun, Apr 23, 2017 at 10:13 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Arnd, > > On Sat, Apr 22, 2017 at 5:30 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> Based on what I found so far, gcc-4 can be pretty much ruled out from >> being the minimum version based on the number of failures I got. >> It's much better than 3.4 but much worse than 4.1 or 4.2 which seem >> fixable on MIPS and x86 at least, and may or may not work depending >> on configuration. So the best two possible (but conflicting) answers I >> have are >> >> a) There are known users on gcc-4.1, and we never break things that >> work for users, so gcc-4.1 (or possibly 4.0 if a user shows up) would >> be the minimum version. >> b) gcc-4.1 and 4.2 have too many problems, so users are better off >> when we tell them to upgrade to something newer, and a minimum >> version of gcc-4.3 has fewer surprises. We should remove all >> workarounds for pre-gcc-4.3 compilers and just force a build error >> message. > > If there's no real good reason (brokenness) to deprecate gcc-4.1, I would not > do it.I guess most people using old compilers know what they're doing. What I'm trying to find out first is whether "people regularly using 10+ year old compilers for the latest kernels" is a strict subset of "people in Geert's household". Given that none of the three architectures I looked at (arm, mips, x86) has successfully built any defconfig for a few years, it's quite possible that it's just you ;-) The other architectures that were around 10 years ago (so they might have someone who still has old toolchain binaries) and that still exist today are alpha, cris, frv, ia64, m32r, parisc, powerpc, s390, sh, sparc and xtensa. The first six are similar to m68k in that the hardware is mostly obsolete and the ports are kept around to support those old systems that might also use ancient toolchains, or new toolchains may be unmaintained or buggy, which could be a reason to keep 4.1 supported or at least try to find out if 4.1 (or even any other version) still works at all. > 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)? > Lately the usefulness has been decreasing, as you've been too aggressively > killing compiler warnings with recent gcc versions (which became better) ;-) > Hence if I detected a new warning with a point or an rc release, it usually > means the code was never in nex (ugh)t, or the maintainer ignored your patch. > > I could easily switch to v4.9 from kernel.org crosstool, though, but then I > would loose all those warnings. If gcc-4.3 produces similarly useful warnings, we could think about integrating gcc-4.3 into kernelci.org build reports as an option, and fix up all the existing warnings we get with that. I wouldn't want to do that with gcc-4.1 though as the older versions have relatively random behavior. One particular feature I'd like to use that requires a newer compiler is being able to control warnings per function liker glibc does, using e.g. '_Pragma("GCC diagnostic disable \"-Woverride-init\"")'. Once we have that, we could turn on a couple of additional warnings that are generally useful but also warn about code that intentionally does something that would trigger the warning. > BTW, below is the diff I use to avoid an ICE. > After that, it builds and (test)boots fine on ARAnyM ;-) I guess this means that even your builds require extra patches and you can't strictly build a defconfig and expect that to work ;-) Arnd
next prev parent reply other threads:[~2017-04-24 9:44 UTC|newest] Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-12-16 10:56 [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6? Arnd Bergmann 2016-12-16 10:56 ` Arnd Bergmann 2016-12-16 10:56 ` [PATCH 01/13] [HACK] gcc-4.5: avoid link errors for unused function pointers Arnd Bergmann 2016-12-16 10:56 ` Arnd Bergmann 2016-12-16 10:56 ` [PATCH 02/13] KVM: arm: fix gcc-4.5 build Arnd Bergmann 2016-12-16 10:56 ` Arnd Bergmann 2017-01-04 10:38 ` Christoffer Dall 2017-01-04 10:38 ` Christoffer Dall 2016-12-16 10:56 ` [PATCH 03/13] ARM: div64: fix building with gcc-4.5 and lower Arnd Bergmann 2016-12-16 10:56 ` Arnd Bergmann 2016-12-16 10:56 ` [PATCH 04/13] vfio-pci: use 32-bit comparisons for register address for gcc-4.5 Arnd Bergmann 2016-12-16 10:56 ` Arnd Bergmann 2016-12-16 15:30 ` Alex Williamson 2016-12-16 19:50 ` Arnd Bergmann 2016-12-16 10:56 ` [PATCH 05/13] clk: pxa: fix gcc-4.4 build Arnd Bergmann 2016-12-16 10:56 ` Arnd Bergmann 2016-12-16 10:56 ` [PATCH 06/13] ARM: atomic: " Arnd Bergmann 2016-12-16 10:56 ` Arnd Bergmann 2016-12-16 10:56 ` [PATCH 07/13] watchdog: kempld: fix gcc-4.3 build Arnd Bergmann 2016-12-16 10:56 ` Arnd Bergmann 2016-12-16 10:56 ` [PATCH 08/13] arm/arm64: xen: avoid gcc-4.4 warning Arnd Bergmann 2016-12-16 10:56 ` Arnd Bergmann 2016-12-16 10:56 ` [PATCH 09/13] ARM: mark cmpxchg and xchg __always_inline for gcc-4.3 Arnd Bergmann 2016-12-16 10:56 ` Arnd Bergmann 2016-12-16 10:56 ` [PATCH 10/13] asm-generic: mark cmpxchg as " Arnd Bergmann 2016-12-16 10:56 ` Arnd Bergmann 2016-12-16 10:56 ` [PATCH 11/13] fs: fix unsigned enum warning with gcc-4.2 Arnd Bergmann 2016-12-16 10:56 ` Arnd Bergmann 2017-01-03 22:47 ` Brendan Gregg 2017-02-28 21:53 ` Brendan Gregg 2016-12-16 10:56 ` [PATCH 12/13] KVM: arm: avoid binary number literals for gcc-4.2 Arnd Bergmann 2016-12-16 10:56 ` Arnd Bergmann 2017-01-04 10:39 ` Christoffer Dall 2017-01-04 10:39 ` Christoffer Dall 2016-12-16 10:56 ` [PATCH 13/13] ARM: avoid 'Q' asm constraint for gcc-4.1 and earlier Arnd Bergmann 2016-12-16 10:56 ` Arnd Bergmann 2016-12-16 11:14 ` [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6? Arnd Bergmann 2016-12-16 11:14 ` Arnd Bergmann 2017-04-16 19:52 ` Kees Cook 2017-04-20 10:15 ` Arnd Bergmann 2017-04-20 19:52 ` Kees Cook 2017-04-20 19:52 ` Kees Cook 2017-04-21 20:55 ` Arnd Bergmann 2017-04-21 20:55 ` Arnd Bergmann 2017-04-21 21:05 ` Kees Cook 2017-04-21 21:05 ` Kees Cook 2017-04-22 3:10 ` Maciej W. Rozycki 2017-04-22 3:10 ` Maciej W. Rozycki 2017-04-22 15:30 ` Arnd Bergmann 2017-04-22 15:30 ` Arnd Bergmann 2017-04-23 20:13 ` Geert Uytterhoeven 2017-04-23 20:13 ` Geert Uytterhoeven 2017-04-24 9:44 ` Arnd Bergmann [this message] 2017-04-24 9:44 ` Arnd Bergmann 2017-04-24 10:17 ` Geert Uytterhoeven 2017-04-24 10:17 ` Geert Uytterhoeven 2017-04-24 14:13 ` Arnd Bergmann 2017-04-24 16:53 ` Maciej W. Rozycki 2017-04-24 17:29 ` Arnd Bergmann 2017-04-24 18:16 ` Geert Uytterhoeven 2017-04-24 18:16 ` Geert Uytterhoeven 2017-04-24 18:30 ` Maciej W. Rozycki 2017-04-24 18:30 ` Maciej W. Rozycki 2017-04-24 20:30 ` Arnd Bergmann 2017-04-24 20:52 ` Kees Cook 2017-04-25 7:06 ` Geert Uytterhoeven 2017-04-25 7:06 ` Geert Uytterhoeven 2017-04-25 9:22 ` Suzuki K Poulose 2017-04-25 9:22 ` Suzuki K Poulose 2016-12-16 15:54 ` Geert Uytterhoeven 2016-12-16 15:54 ` Geert Uytterhoeven 2016-12-16 19:58 ` Arnd Bergmann 2016-12-16 19:58 ` Arnd Bergmann 2016-12-16 20:34 ` Geert Uytterhoeven 2016-12-16 20:34 ` Geert Uytterhoeven 2016-12-16 17:00 ` Sebastian Andrzej Siewior 2016-12-16 22:00 ` Arnd Bergmann 2016-12-16 22:00 ` Arnd Bergmann 2016-12-17 11:29 ` Sebastian Andrzej Siewior 2016-12-17 11:29 ` Sebastian Andrzej Siewior 2017-01-02 12:23 ` Russell King - ARM Linux 2017-01-02 12:23 ` Russell King - ARM Linux 2016-12-20 9:59 ` Heiko Carstens 2016-12-20 9:59 ` Heiko Carstens
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAK8P3a32Y0AiKyVaotYb14uZZ1jM=nwhFD1vyP56epW1Y9KqSw@mail.gmail.com' \ --to=arnd@arndb.de \ --cc=akpm@linux-foundation.org \ --cc=geert@linux-m68k.org \ --cc=keescook@chromium.org \ --cc=kernel-build-reports@lists.linaro.org \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kbuild@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=macro@linux-mips.org \ --cc=rmk+kernel@armlinux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).