On Fri, Dec 16, 2016 at 11:56:23AM +0100, Arnd Bergmann wrote:

Old gcc versions cannot used named initializers for anonymous unions, leading to a build failure here. This replaces the anonymous union with a named one, which allows us to build with at least gcc-4.3 through 4.5. Versions 4.6 and higher are fine without this.

virt/kvm/arm/vgic/vgic-mmio-v2.c:295: error: unknown field 'read' specified in initializer virt/kvm/arm/vgic/vgic-mmio-v2.c:295: warning: missing braces around initializer virt/kvm/arm/vgic/vgic-mmio-v2.c:295: warning: (near initialization for 'vgic_v2_dist_registers[0].<anonymous>') virt/kvm/arm/vgic/vgic-mmio-v2.c:295: error: unknown field 'write' specified in initializer virt/kvm/arm/vgic/vgic-mmio-v2.c:298: error: unknown field 'read' specified in initializer

Fixes: 59c5ab40989a ("KVM: arm64: vgic-its: Introduce ITS emulation file with MMIO framework") Signed-off-by: Arnd Bergmann arnd@arndb.de

If this series is moving ahead, I have no problems with this patch:

Acked-by: Christoffer Dall christoffer.dall@linaro.org

On Friday, December 16, 2016 8:30:56 AM CET Alex Williamson wrote:

Acked-by: Alex Williamson alex.williamson@redhat.com

Would you like me to pull this one patch in through the vfio tree? Thanks,

If you think the patch is appropriate, please merge it.

I originally just posted this as illustration to raise the question of whether we actually want to support gcc-4.5, from the feedback so far it does seem like the answer is yes, and we will need it.

Arnd

Was there a conclusion to this discussion? I didn't see anything definitive in the thread...

Notes below...

On Fri, Dec 16, 2016 at 3:14 AM, Arnd Bergmann arnd@arndb.de wrote:

[Fixed linux-arm-kernel mailing list address, sorry for the duplicate, I'm not reposting all the ugly patches though, unless someone really wants them, https://lkml.org/lkml/2016/12/16/174 has a copy]

On Friday, December 16, 2016 11:56:21 AM CET Arnd Bergmann wrote:

...

I had some fun doing build testing with older gcc versions, building every release from 4.0 through 7.0 and running that on my randconfig setup to see what comes out.

First of all, gcc-4.9 and higher is basically warning-free everywhere, although gcc-7 introduces some interesting new warnings (I have started doing patches for those as well). gcc-4.8 is probably good, too, and gcc-4.6 and 4.7 at least don't produce build failures in general, though the level of false-positive warnings increases (we could decide to turn those off for older compilers for build test purposes).

In gcc-4.5 and below, dead code elimination is not as good as later, causing a couple of link errors, and some of them have no good workaround (see patch 1). It would be nice to declare that version too old, but several older distros that are still in wide use ship with compilers earlier than 4.6:

RHEL6: gcc-4.4

This appears to have support until July 31, 2018. (Though it's using a 2.6 kernel.)

...

Debian 6: gcc-4.4

This went fully unsupported on Feb 29, 2016.

...

Ubuntu 10.04: gcc-4.4

This went fully unsupported on Apr 30, 2015.

...

SLES11: gcc-4.3

General support ends Mar 31 2019, fully unsupported 31 Mar 2022. (And like RHEL6 is using a 2.6 kernel.)

...

With gcc-4.3, we need a couple of workaround patches beyond the problem mentioned above, more configuration options are unavailable and we get a significant number of false-positive warnings, but it's not much worse than gcc-4.5 otherwise.

These are the options I had to disable to get gcc-4.3 randconfig builds working:

CONFIG_HAVE_GCC_PLUGINS

This needs gcc 4.5, with 4.7 preferred.

...

CONFIG_CC_STACKPROTECTOR_STRONG

Introduced in gcc 4.9.

...

CONFIG_ARM_SINGLE_ARMV7M CONFIG_THUMB2_KERNEL CONFIG_KERNEL_MODE_NEON CONFIG_VDSO CONFIG_FUNCTION_TRACER (with CONFIG_FRAME_POINTER=n)

I have not checked in detail which version is required for each of the above.

Specifically on ARM, going further makes things rather useless especially for build testing: with gcc-4.2, we lose support for ARMv7, EABI, and effectively ARMv6 (as it relies on EABI for building reliably). Also, the number of false-positive build warnings is so high that it is useless for finding actual bugs from the warnings.

See the replies to this mail for 13 patches I needed to work around issues for each of the releases before 4.6. I have also submitted some separate patches for issues that I considered actual bugs uncovered by the older compilers and that should be applied regardless.

The original gcc-4.3 release was in early 2008. If we decide to still support that, we probably want the first 10 quirks in this series, while gcc-4.6 (released in 2011) requires none of them.

I'd be in support of raising the minimum to gcc 4.6. (I'd actually prefer 4.7, just to avoid some 4.6 packaging issues, and for better gcc plugin support.)

I'm curious what gcc 4.6 binaries are common in the wild besides old-stable Debian (unsupported in maybe a year from now?) and 12.04 Ubuntu (going fully unsupported in 2 weeks). It looks like 4.6 was used only in Fedora 15 and 16 (both EOL).

-Kees

On Thu, Apr 20, 2017 at 3:15 AM, Arnd Bergmann arnd@arndb.de wrote:

On Sun, Apr 16, 2017 at 9:52 PM, Kees Cook keescook@chromium.org wrote:

...

...

...

The original gcc-4.3 release was in early 2008. If we decide to still support that, we probably want the first 10 quirks in this series, while gcc-4.6 (released in 2011) requires none of them.

I'd be in support of raising the minimum to gcc 4.6. (I'd actually prefer 4.7, just to avoid some 4.6 packaging issues, and for better gcc plugin support.)

I'm curious what gcc 4.6 binaries are common in the wild besides old-stable Debian (unsupported in maybe a year from now?) and 12.04 Ubuntu (going fully unsupported in 2 weeks). It looks like 4.6 was used only in Fedora 15 and 16 (both EOL).

I think we are better off defining two versions: One that we know a lot of people care about, and we actively try to make that work well in all configurations (e.g. 4.6, 4.7 or 4.8), fixing all warnings we run into, and an older version that we try not to break intentionally (e.g. 3.4, 4.1 or 4.3) but that we only fix when someone actually runs into a problem they can't work around by upgrading to a more modern compiler.

For "working well everywhere" I feel like 4.8 is the better of those three (I'd prefer 4.9). I think we should avoid 4.6 -- it seems not widely used.

For an old compiler... yikes. 3.4 sounds insane to me. :)

-Kees

On Fri, Apr 21, 2017 at 1:55 PM, Arnd Bergmann arnd@arndb.de wrote:

On Thu, Apr 20, 2017 at 9:52 PM, Kees Cook keescook@chromium.org wrote:

...

On Thu, Apr 20, 2017 at 3:15 AM, Arnd Bergmann arnd@arndb.de wrote:

...

On Sun, Apr 16, 2017 at 9:52 PM, Kees Cook keescook@chromium.org wrote:

...

...

...

The original gcc-4.3 release was in early 2008. If we decide to still support that, we probably want the first 10 quirks in this series, while gcc-4.6 (released in 2011) requires none of them.

I'd be in support of raising the minimum to gcc 4.6. (I'd actually prefer 4.7, just to avoid some 4.6 packaging issues, and for better gcc plugin support.)

I'm curious what gcc 4.6 binaries are common in the wild besides old-stable Debian (unsupported in maybe a year from now?) and 12.04 Ubuntu (going fully unsupported in 2 weeks). It looks like 4.6 was used only in Fedora 15 and 16 (both EOL).

I think we are better off defining two versions: One that we know a lot of people care about, and we actively try to make that work well in all configurations (e.g. 4.6, 4.7 or 4.8), fixing all warnings we run into, and an older version that we try not to break intentionally (e.g. 3.4, 4.1 or 4.3) but that we only fix when someone actually runs into a problem they can't work around by upgrading to a more modern compiler.

For "working well everywhere" I feel like 4.8 is the better of those three (I'd prefer 4.9). I think we should avoid 4.6 -- it seems not widely used.

I suspect that 4.9 might be the one that actually works best across architectures, and it contained some very significant changes. In my testing gcc-5 tends to behave very similarly to 4.9, and gcc-6 introduced a larger number of new warnings, so that would clearly be too new for a recommended version.

The suggestion of 4.9 or higher is appealing as a recommendation because it matches what I would personally tell people:

• If you have gcc-4.9 or newer and you don't rely on any newer features, there is no need to upgrade
• Wth gcc-4.8, the -Wmaybe-uninitialized warnings are now turned off because they were too noisy, so upgrading is probably a good idea even though the compiler is otherwise ok and in widespread use
• gcc-4.6 and 4.7 are basically usable for building kernels, but the warning output is often counterproductive, and the generated object code may be noticeably worse.
• anything before gcc-4.6 is missing too many features to be useful on ARM, but may still be fine on other architectures.

On the other hand, there is a noticeable difference in compile speed, as a 5% slowdown compared to the previous release apparently is not considered a regression. These are the times I see for building ARM 'vexpress_defconfig':

gcc-4.4: real 0m47.269s user 11m48.576s gcc-4.5: real 0m44.878s user 10m58.900s gcc-4.6: real 0m44.621s user 11m34.716s gcc-4.7: real 0m47.476s user 12m42.924s gcc-4.8: real 0m48.494s user 13m19.736s gcc-4.9: real 0m50.140s user 13m44.876s gcc-5.x: real 0m51.302s user 14m05.564s gcc-6.x: real 0m54.615s user 15m06.304s gcc-7.x: real 0m56.008s user 15m44.720s

That is a factor of 1.5x in CPU cycles between slowest and fastest, so there is clearly a benefit to keeping the old versions around, but there is also no clear cut-off other thannoticing that gcc-4.4 is slower than 4.5 in this particular configuration.

...

For an old compiler... yikes. 3.4 sounds insane to me. :)

That was my initial thought as well. On ARM, it clearly is insane, as even gcc-4.0 is unable to build any of the modern defconfigs (lacking -mabi=aapcs, ICE when building vsprintf.c) and even the patch I did to get gcc-4.1 to build is probably too ugly to get merged, so to build any unpatched kernel after linux-3.6 you need at least gcc-4.2, or even gcc-4.4 for the ''defconfig' (gcc-4.3 if you disable vdso).

Then again, on x86, old cmpilers were claimed to be much better supported. I just tried it out and found that no x86 defconfig kernel since linux-3.2 could be built with gcc-3.4, probably not on any other architecture either (it cannot have forward declarations for inline functions and we have one in kernel/sched_fair.c).

I think that would be a really good argument for requiring something newer ;-)

The linux-4.2 x86 defconfig could still be built with gcc-4.0, but later kernels have several minor problems with that, and require at least gcc-4.3.

If we are ok with this status quo, we could simply declare gcc-4.3 the absolute minimum version for the kernel, make gcc-4.9 the recommeded minimum version, and remove all workarounds for gcc-4.2 or older.

I think starting with this would be a good first step. I'm not sure the best way to add "recommended minimum" to Documentation/process/changes.rst hmmm

If anyone has a good reason for gcc-4.0 through gcc-4.2, then we would need a small number of patches to get them back working with x86 defconfig.

-Kees

On Sat, Apr 22, 2017 at 5:10 AM, Maciej W. Rozycki macro@linux-mips.org wrote:

On Fri, 21 Apr 2017, Kees Cook wrote:

...

...

The linux-4.2 x86 defconfig could still be built with gcc-4.0, but later kernels have several minor problems with that, and require at least gcc-4.3.

If we are ok with this status quo, we could simply declare gcc-4.3 the absolute minimum version for the kernel, make gcc-4.9 the recommeded minimum version, and remove all workarounds for gcc-4.2 or older.

I think starting with this would be a good first step. I'm not sure the best way to add "recommended minimum" to Documentation/process/changes.rst hmmm

FWIW for some reasons (mainly the ability to avoid NPTL) I have stuck to GCC 4.1.2 with some MIPS configurations and I've had no issues with that compiler up to Linux 4.6.0, which is the last kernel version I have tried with that compiler so far. I could check if anything has regressed since then I suppose.

Interesting. This is also the same version that Geert mentioned using on m68k. I've tried some more x86 and mips builds now and found:

- x86 defconfig broke because the i915 driver relies on gcc-4.3 behavior for alignment attributes as of a few kernel versions ago for the sw_fence mechanism: drivers/gpu/drm/i915/intel_display.c:14571: error: alignment may not be specified for 'intel_atomic_commit_ready'

- With gcc-4.0 I also get a couple of BUILD_BUG_ON() triggering for correct code that it doesn't always consider compile-time constant (on all architectures), this is from x86 defconfig starting around linux-4.3: mm/built-in.o: In function `do_set_pmd': memory.c:(.text+0x34df5): undefined reference to `__compiletime_assert_3157' drivers/built-in.o: In function `cea_mode_alternate_timings': drm_edid.c:(.text+0x10858a): undefined reference to `__compiletime_assert_2641'

- gcc-4.0 has been broken for all MIPS configurations (but no other arch) since commit 51b97e354ba9 ("kernel: use the gnu89 standard explicitly") in 3.18, the problem still exists in stable/linux-3.18.y and mainline but would be trivial to fix with a oneline patch if anyone had noticed this before me. arch/mips/kernel/vmlinux.lds.S:110:1: error: pasting "initcall0" and "." does not give a valid preprocessing token

- The interprocedural optimization changes in gcc-4.3 mean that the object code is a bit different, and we no longer expect the pre-gcc-4.3 behavior. This mostly results in warnings (e.g. maybe-uninitialized or section mismatch) when the compiler and/or linker lacks the information to see that the code is actually correct. On x86 I only got one failure with gcc-4.1, on mips-gcc-4.1 I got this and a few more depending on configuration: mm/built-in.o: In function `create_huge_pmd': memory.c:(.text+0x34e71): undefined reference to `do_huge_pmd_anonymous_page'

The last one is the key here I think. The linker warnings and errors we run into here are all fairly easy to fix, but we will keep running into new ones since evidently nobody does regular builds checking for them, and they can appear randomly based on configuration for otherwise acceptable code. Today, most configurations I tried were broken because of this, and if things worked for you, you were either lucky that you didn't run into the same bugs (or that Geert fixed the ones you would have hit) or you had patches on top to work around them already.

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.

Arnd

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

On Mon, Apr 24, 2017 at 12:17 PM, Geert Uytterhoeven geert@linux-m68k.org wrote:

On Mon, Apr 24, 2017 at 11:44 AM, Arnd Bergmann arnd@arndb.de wrote:

...

On Sun, Apr 23, 2017 at 10:13 PM, Geert Uytterhoeven geert@linux-m68k.org wrote:

...

On Sat, Apr 22, 2017 at 5:30 PM, Arnd Bergmann arnd@arndb.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

On Mon, Apr 24, 2017 at 6:53 PM, Maciej W. Rozycki macro@linux-mips.org wrote:

On Mon, 24 Apr 2017, Arnd Bergmann wrote:

...

...

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".

Well I do not live with Geert TBH.

Sorry about that, you had mentioned that you had used it recently, which should have weighed more than my own results.

Linux 4.11-rc8

$ /usr/bin/time make ARCH=mips CROSS_COMPILE=mipsel-linux- decstation_defconfig vmlinux >/dev/null 2>&1 1014.19user 71.47system 19:33.24elapsed 92%CPU (0avgtext+0avgdata 0maxresident)k18764inputs+242504outputs (704major+9549837minor)pagefaults 0swaps $ mipsel-linux-gcc --version gcc (GCC) 4.1.2 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $

Methinks it builds just fine.

I must have done something wrong:

I tried a few defconfigs with a latest kernel and compiler and they all failed, found linux-4.3 to be the first version that was broken for all of them (most with a link time error, some with missing gcc features)

I later tried all mips defconfigs with linux-4.3 and they all failed with gcc-4.1.3 but built fine with gcc-4.9. I've now tried decstation_defconfig in 4.8-rc11, and this is what I see for gcc-4.1.3

make O=build/mips/decstation_defconfig/ -skj30 CC=/home/arnd/cross-gcc/bin/mips-linux-gcc-4.1.3\ ARCH=mips -f Makefile CROSS_COMPILE=/home/arnd/cross-gcc/bin/mips-linux- /git/arm-soc/fs/dcache.c: In function '__d_move': /git/arm-soc/fs/dcache.c:2773: warning: 'n' may be used uninitialized in this function /git/arm-soc/fs/dcache.c: In function 'd_splice_alias': /git/arm-soc/fs/dcache.c:2529: warning: 'n' may be used uninitialized in this function /git/arm-soc/fs/dcache.c: In function 'd_add': /git/arm-soc/fs/dcache.c:2529: warning: 'n' may be used uninitialized in this function /git/arm-soc/mm/page-writeback.c: In function 'balance_dirty_pages_ratelimited': /git/arm-soc/mm/page-writeback.c:1627: warning: 'writeback' is used uninitialized in this function /git/arm-soc/mm/page-writeback.c:1628: warning: 'filepages' is used uninitialized in this function /git/arm-soc/mm/page-writeback.c:1628: warning: 'headroom' is used uninitialized in this function /git/arm-soc/mm/page-writeback.c: In function 'wb_over_bg_thresh': /git/arm-soc/mm/page-writeback.c:1956: warning: 'filepages' is used uninitialized in this function /git/arm-soc/mm/page-writeback.c:1956: warning: 'headroom' is used uninitialized in this function /git/arm-soc/net/core/flow_dissector.c: In function '__skb_flow_dissect': /git/arm-soc/net/core/flow_dissector.c:272: warning: 'vlan' may be used uninitialized in this function /git/arm-soc/fs/splice.c: In function 'iter_file_splice_write': /git/arm-soc/fs/splice.c:716: warning: 'ret' may be used uninitialized in this function /git/arm-soc/net/core/dev.c: In function 'validate_xmit_skb_list': /git/arm-soc/net/core/dev.c:3003: warning: 'tail' may be used uninitialized in this function /git/arm-soc/kernel/printk/printk.c: In function 'devkmsg_sysctl_set_loglvl': /git/arm-soc/kernel/printk/printk.c:161: warning: 'old' may be used uninitialized in this function /git/arm-soc/kernel/time/ntp.c: In function 'ntp_validate_timex': /git/arm-soc/kernel/time/ntp.c:707: warning: comparison is always false due to limited range of data type /git/arm-soc/kernel/time/ntp.c:709: warning: comparison is always false due to limited range of data type /git/arm-soc/kernel/time/timekeeping.c: In function 'get_device_system_crosststamp': /git/arm-soc/kernel/time/timekeeping.c:1084: warning: 'cs_was_changed_seq' may be used uninitialized in this function /git/arm-soc/net/sunrpc/xdr.c: In function 'xdr_stream_decode_string_dup': /git/arm-soc/include/linux/sunrpc/xdr.h:409: warning: 'len' may be used uninitialized in this function /git/arm-soc/crypto/drbg.c: In function 'drbg_kcapi_random': /git/arm-soc/crypto/drbg.c:1865: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. /git/arm-soc/scripts/Makefile.build:300: recipe for target 'crypto/drbg.o' failed

So it still fails, but only because of one compiler error that I can avoid by disabling that driver, and you probably use a slightly patched compiler version that doesn't have this particular bug, or it was a regression between gcc-4.1.2 and 4.1.3.

Arnd

On Mon, 24 Apr 2017, Arnd Bergmann wrote:

I later tried all mips defconfigs with linux-4.3 and they all failed with gcc-4.1.3 but built fine with gcc-4.9. I've now tried decstation_defconfig in 4.8-rc11, and this is what I see for gcc-4.1.3

make O=build/mips/decstation_defconfig/ -skj30 CC=/home/arnd/cross-gcc/bin/mips-linux-gcc-4.1.3\ ARCH=mips -f Makefile CROSS_COMPILE=/home/arnd/cross-gcc/bin/mips-linux- /git/arm-soc/fs/dcache.c: In function '__d_move': /git/arm-soc/fs/dcache.c:2773: warning: 'n' may be used uninitialized in this function /git/arm-soc/fs/dcache.c: In function 'd_splice_alias': /git/arm-soc/fs/dcache.c:2529: warning: 'n' may be used uninitialized in this function /git/arm-soc/fs/dcache.c: In function 'd_add': /git/arm-soc/fs/dcache.c:2529: warning: 'n' may be used uninitialized in this function /git/arm-soc/mm/page-writeback.c: In function 'balance_dirty_pages_ratelimited': /git/arm-soc/mm/page-writeback.c:1627: warning: 'writeback' is used uninitialized in this function /git/arm-soc/mm/page-writeback.c:1628: warning: 'filepages' is used uninitialized in this function /git/arm-soc/mm/page-writeback.c:1628: warning: 'headroom' is used uninitialized in this function /git/arm-soc/mm/page-writeback.c: In function 'wb_over_bg_thresh': /git/arm-soc/mm/page-writeback.c:1956: warning: 'filepages' is used uninitialized in this function /git/arm-soc/mm/page-writeback.c:1956: warning: 'headroom' is used uninitialized in this function /git/arm-soc/net/core/flow_dissector.c: In function '__skb_flow_dissect': /git/arm-soc/net/core/flow_dissector.c:272: warning: 'vlan' may be used uninitialized in this function /git/arm-soc/fs/splice.c: In function 'iter_file_splice_write': /git/arm-soc/fs/splice.c:716: warning: 'ret' may be used uninitialized in this function /git/arm-soc/net/core/dev.c: In function 'validate_xmit_skb_list': /git/arm-soc/net/core/dev.c:3003: warning: 'tail' may be used uninitialized in this function /git/arm-soc/kernel/printk/printk.c: In function 'devkmsg_sysctl_set_loglvl': /git/arm-soc/kernel/printk/printk.c:161: warning: 'old' may be used uninitialized in this function /git/arm-soc/kernel/time/ntp.c: In function 'ntp_validate_timex': /git/arm-soc/kernel/time/ntp.c:707: warning: comparison is always false due to limited range of data type /git/arm-soc/kernel/time/ntp.c:709: warning: comparison is always false due to limited range of data type /git/arm-soc/kernel/time/timekeeping.c: In function 'get_device_system_crosststamp': /git/arm-soc/kernel/time/timekeeping.c:1084: warning: 'cs_was_changed_seq' may be used uninitialized in this function /git/arm-soc/net/sunrpc/xdr.c: In function 'xdr_stream_decode_string_dup': /git/arm-soc/include/linux/sunrpc/xdr.h:409: warning: 'len' may be used uninitialized in this function /git/arm-soc/crypto/drbg.c: In function 'drbg_kcapi_random': /git/arm-soc/crypto/drbg.c:1865: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. /git/arm-soc/scripts/Makefile.build:300: recipe for target 'crypto/drbg.o' failed

So it still fails, but only because of one compiler error that I can avoid by disabling that driver, and you probably use a slightly patched compiler version that doesn't have this particular bug, or it was a regression between gcc-4.1.2 and 4.1.3.

Umm, I didn't build modules, sorry, because I don't usually use them with those systems. However I have completed this step now and it also worked just fine:

$ ls -la crypto/drbg.o -rw-r--r-- 1 macro macro 14096 Apr 24 18:59 crypto/drbg.o $ file crypto/drbg.o crypto/drbg.o: ELF 32-bit LSB MIPS-I relocatable, MIPS, version 1 (SYSV), not stripped $

so you are likely right that either I have a patch applied to my 4.1.2 build that has somehow fixed the ICE or it is a 4.1.3 regression (or a bad patch in your 4.1.3 build).

BTW I do see these `may be used uninitialized' warnings just as Geert does and even have a local patch, which I have neglected to submit, for a 64-bit configuration (`decstation_defconfig' is 32-bit) where in a single place -Werror turns it into a build failure. I do not consider it a big issue though, and might even wrap that patch up and submit sometime.

Maciej

On Mon, Apr 24, 2017 at 1:30 PM, Arnd Bergmann arnd@arndb.de wrote:

How about this approach then:

• To keep it simple, we update the README.rst to say that a minimum gcc-4.3 is required, while recommending gcc-4.9 for all architectures
• Support for gcc-4.0 and earlier gets removed from linux/compiler.h, and instead we add a summary of what I found, explaining that gcc-4.1 has active users on a few architectures.
• We make the Makefile show a warning once during compilation for gcc earlier than 4.3.

This sounds good to me!

-Kees

On 16/04/17 20:52, Kees Cook wrote:

Was there a conclusion to this discussion? I didn't see anything definitive in the thread...

Notes below...

On Fri, Dec 16, 2016 at 3:14 AM, Arnd Bergmann arnd@arndb.de wrote:

...

[Fixed linux-arm-kernel mailing list address, sorry for the duplicate, I'm not reposting all the ugly patches though, unless someone really wants them, https://lkml.org/lkml/2016/12/16/174 has a copy]

On Friday, December 16, 2016 11:56:21 AM CET Arnd Bergmann wrote:

...

I had some fun doing build testing with older gcc versions, building every release from 4.0 through 7.0 and running that on my randconfig setup to see what comes out.

First of all, gcc-4.9 and higher is basically warning-free everywhere, although gcc-7 introduces some interesting new warnings (I have started doing patches for those as well). gcc-4.8 is probably good, too, and gcc-4.6 and 4.7 at least don't produce build failures in general, though the level of false-positive warnings increases (we could decide to turn those off for older compilers for build test purposes).

In gcc-4.5 and below, dead code elimination is not as good as later, causing a couple of link errors, and some of them have no good workaround (see patch 1). It would be nice to declare that version too old, but several older distros that are still in wide use ship with compilers earlier than 4.6:

RHEL6: gcc-4.4

This appears to have support until July 31, 2018. (Though it's using a 2.6 kernel.)

...

...

Debian 6: gcc-4.4

This went fully unsupported on Feb 29, 2016.

...

...

Ubuntu 10.04: gcc-4.4

This went fully unsupported on Apr 30, 2015.

...

...

SLES11: gcc-4.3

General support ends Mar 31 2019, fully unsupported 31 Mar 2022. (And like RHEL6 is using a 2.6 kernel.)

fyi, SLES11 upgraded to kernel 3.0, in SP2.

https://www.novell.com/support/kb/doc.php?id=3594951

Cheers Suzuki

On Friday, December 16, 2016 4:54:33 PM CET Geert Uytterhoeven wrote:

Hi Arnd,

On Fri, Dec 16, 2016 at 11:56 AM, Arnd Bergmann arnd@arndb.de wrote:

...

Specifically on ARM, going further makes things rather useless especially for build testing: with gcc-4.2, we lose support for ARMv7, EABI, and effectively ARMv6 (as it relies on EABI for building reliably). Also, the number of false-positive build warnings is so high that it is useless for finding actual bugs from the warnings.

If you start with that activity now, there's indeed a massive amount of warnings to look into. However, I've been build testing various configs with m68k-linux-gnu-gcc-4.1.2 and looking at the compiler warnings for years, so I only have to look at new warnings.

What's the reason for sticking with gcc-4.1? Does this actually work better for you than a more recent version, or is it just whatever you installed when you started the build testing?

Arnd

On 2016-12-16 23:00:27 [+0100], Arnd Bergmann wrote:

On Friday, December 16, 2016 6:00:43 PM CET Sebastian Andrzej Siewior wrote:

...

On 2016-12-16 11:56:21 [+0100], Arnd Bergmann wrote:

...

The original gcc-4.3 release was in early 2008. If we decide to still support that, we probably want the first 10 quirks in this series, while gcc-4.6 (released in 2011) requires none of them.

It this min gcc thingy ARM only?

This is part of the question that I'm trying to figure out myself.

Clearly having the same minimum version across all architectures simplifies things a lot, because many of the bugs in old versions are architecture independent.

agreed.

Then again, some architectures implicitly require a new version because an old one never existed (e.g. arm64 or risc-v), while some other architectures may require an old version.

A new version is understandable. But why is an old version required? One thing is an enterprise distro that is "current" or "supported" and still stuck with gcc 4.1 because that is the version they decided to include in their release. This is sad. But you might want to ask yourself why you want the latest kernel but an old gcc / binutils.

If you have an architecture that compiles with gcc v4.1 and not with gcc latest stable / trunk then it is a sign that this port is not supported properly / not heatly. One thing is something like avr32 which is not part of upstream gcc due to some legal reason (that was my understanding a few years ago). It might get to a problem for them once large parts of userland switch to a later C++ standard which is gcc-5+.

Arnd

Sebastian

On Fri, Dec 16, 2016 at 11:00:27PM +0100, Arnd Bergmann wrote:

On Friday, December 16, 2016 6:00:43 PM CET Sebastian Andrzej Siewior wrote:

...

On 2016-12-16 11:56:21 [+0100], Arnd Bergmann wrote:

...

The original gcc-4.3 release was in early 2008. If we decide to still support that, we probably want the first 10 quirks in this series, while gcc-4.6 (released in 2011) requires none of them.

It this min gcc thingy ARM only?

This is part of the question that I'm trying to figure out myself.

Clearly having the same minimum version across all architectures simplifies things a lot, because many of the bugs in old versions are architecture independent. Then again, some architectures implicitly require a new version because an old one never existed (e.g. arm64 or risc-v), while some other architectures may require an old version.

FWIW, s390 requires gcc 4.3 or newer since two years already. For older compilers we enforce a compile error (see arch/s390/kernel/asm-offsets.c).