On Thu, Apr 20, 2017 at 9:52 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > On Thu, Apr 20, 2017 at 3:15 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> On Sun, Apr 16, 2017 at 9:52 PM, Kees Cook <keescook@xxxxxxxxxxxx> 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. 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. 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