Hi Arnd,
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:
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".
Fair enough.
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.
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.
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.
And as long as I find real bugs this way, I'd like to continue doing it.
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 ;-)
No sane people enable GFS in defconfig, so it's not affected.
Oh wait, some mips, powerpc, s390, and tile do ;-)
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds