On Sun, Apr 23, 2017 at 10:13 PM, Geert Uytterhoeven
<geert@xxxxxxxxxxxxxx> wrote:
> Hi Arnd,
>
> On Sat, Apr 22, 2017 at 5:30 PM, Arnd Bergmann <arnd@xxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
