On Sun, Feb 11, 2018 at 10:50 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Sun, Feb 11, 2018 at 1:19 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >> On Sun, Feb 11, 2018 at 1:10 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >>> >>> In my tests last year, I identified gcc-4.6 as a nice minimum level, IIRC >>> gcc-4.5 was unable to build some of the newer ARM targets. >> >> But yes, if Linus wants 4.5 over 4.3, I would agree with Arnd: let's >> take it to 4.6 instead. > > So it sounds like Arnd knows what the distros have. ... > If no distro is on 4.5, then there's no reason to pick that. The > reason I mentioned 4.5 is because that's the "asm goto" point, afaik, > and that is likely to be a requirement in the near future. Looking at old distros with long support cycles: Red Hat have either gcc-4.1 (EL5, extended support ends 2020) or gcc-4.4 (EL6, regular support ends 2020, extended support ends 2024): https://access.redhat.com/solutions/19458 EL7 uses gcc-4.8 and will be supported until 2024 (no extended support planned) SUSE have gcc-4.3 (SLES11, extended support ends 2022) or gcc-4.8 (SLES12, support ends 2024, extended support ends 2027): https://www.suse.com/lifecycle/ Debian Jessie (oldstable) comes with gcc-4.8 and is supported until June 2018, extended support until 2020 Debian Wheezy (oldoldstable) uses gcc-4.6 or 4.7 depending on the architecture, extended support ends May 2018. Ubuntu 14.04 is supported until 2019 and uses gcc-4.8 The latest Android SDK provides (known broken) versions of gcc-4.8 and gcc-4.9 as well as clang. OpenWRT 14.07 Barrier Breaker uses gcc-4.8, 12.07 Attitude Adjustment 12.09 used gcc-4.6, but it's very unlikely that anyone cares about building new kernels with either. Most embedded distros just build everything from source and are used to adapting to new requirements. >From that list above, it sounds like going all the way to gcc-4.8 would be a better candidate than 4.5 or 4.6, if we decide that 4.3 and 4.4 are both no longer desirable to support. > If SLES11 is 4.3, that's obviously a concern. Although Arnd seemed to > imply that that had already caused problems, so... The problems are mainly an excessive amount of false-positive warnings, which makes it tricky to new warnings when you make a mistake. 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