From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann 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 Message-ID: References: <20161216105634.235457-1-arnd@arndb.de> <3302470.IDcDrWa0u6@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu To: Geert Uytterhoeven Cc: linux-arch , Kees Cook , linux-kbuild , kernel-build-reports@lists.linaro.org, LKML , Russell King , "Maciej W. Rozycki" , Andrew Morton , kvmarm@lists.cs.columbia.edu, "linux-arm-kernel@lists.infradead.org" List-Id: linux-arch.vger.kernel.org On Sun, Apr 23, 2017 at 10:13 PM, Geert Uytterhoeven wrote: > Hi Arnd, > > On Sat, Apr 22, 2017 at 5:30 PM, Arnd Bergmann 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f177.google.com ([209.85.223.177]:36302 "EHLO mail-io0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1168193AbdDXJo2 (ORCPT ); Mon, 24 Apr 2017 05:44:28 -0400 MIME-Version: 1.0 In-Reply-To: References: <20161216105634.235457-1-arnd@arndb.de> <3302470.IDcDrWa0u6@wuerfel> From: Arnd Bergmann Date: Mon, 24 Apr 2017 11:44:26 +0200 Message-ID: Subject: Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6? Content-Type: text/plain; charset=UTF-8 Sender: linux-arch-owner@vger.kernel.org List-ID: To: Geert Uytterhoeven Cc: "Maciej W. Rozycki" , Kees Cook , linux-arch , linux-kbuild , LKML , "linux-arm-kernel@lists.infradead.org" , Russell King , Andrew Morton , kernel-build-reports@lists.linaro.org, kvmarm@lists.cs.columbia.edu Message-ID: <20170424094426.6icMfOpjxz45Pr8QMzLvGvcW1h55tOpc4hAhR6O9LJ4@z> On Sun, Apr 23, 2017 at 10:13 PM, Geert Uytterhoeven wrote: > Hi Arnd, > > On Sat, Apr 22, 2017 at 5:30 PM, Arnd Bergmann 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