[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Arnd Bergmann]

[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
>  Debian 6:	gcc-4.4
>  Ubuntu 10.04:	gcc-4.4
>  SLES11:	gcc-4.3
> 
> 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
>  CONFIG_CC_STACKPROTECTOR_STRONG
>  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.
> 
> 	Arnd
> 
> Arnd Bergmann (13):
>   [HACK] gcc-4.5: avoid  link errors for unused function pointers
>   KVM: arm: fix gcc-4.5 build
>   ARM: div64: fix building with gcc-4.5 and lower
>   vfio-pci: use 32-bit comparisons for register address for gcc-4.5
>   clk: pxa: fix gcc-4.4 build
>   ARM: atomic: fix gcc-4.4 build
>   watchdog: kempld: fix gcc-4.3 build
>   arm/arm64: xen: avoid gcc-4.4 warning
>   ARM: mark cmpxchg and xchg __always_inline for gcc-4.3
>   asm-generic: mark cmpxchg as __always_inline for gcc-4.3
>   fs: fix unsigned enum warning with gcc-4.2
>   KVM: arm: avoid binary number literals for gcc-4.2
>   ARM: avoid 'Q' asm constraint for gcc-4.1 and earlier
> 
>  arch/arm/include/asm/atomic.h        | 10 ++++++++--
>  arch/arm/include/asm/cmpxchg.h       | 12 ++++++------
>  arch/arm/include/asm/div64.h         | 17 +++--------------
>  arch/arm/include/asm/io.h            |  8 ++++++++
>  arch/arm/include/asm/kvm_mmu.h       |  2 +-
>  arch/arm/include/asm/percpu.h        |  5 ++++-
>  arch/arm/mach-imx/pm-imx5.c          | 20 ++++++++++++++++----
>  arch/arm/mach-sa1100/pm.c            |  2 ++
>  arch/arm/plat-samsung/pm.c           |  4 ++++
>  drivers/clk/pxa/clk-pxa.c            |  3 +--
>  drivers/dma/ti-dma-crossbar.c        |  4 ++++
>  drivers/firmware/psci_checker.c      |  3 +++
>  drivers/iio/adc/exynos_adc.c         |  3 +++
>  drivers/net/ethernet/via/via-rhine.c |  6 ++++++
>  drivers/vfio/pci/vfio_pci_rdwr.c     |  5 ++++-
>  drivers/watchdog/kempld_wdt.c        |  9 ++++++++-
>  include/asm-generic/cmpxchg-local.h  |  7 ++++---
>  include/linux/fs.h                   |  2 +-
>  include/xen/arm/page.h               |  1 +
>  virt/kvm/arm/vgic/vgic-its.c         |  4 ++--
>  virt/kvm/arm/vgic/vgic-mmio-v3.c     |  8 ++++----
>  virt/kvm/arm/vgic/vgic-mmio.c        | 16 ++++++++--------
>  virt/kvm/arm/vgic/vgic-mmio.h        | 12 ++++++------
>  23 files changed, 107 insertions(+), 56 deletions(-)
> 
> 

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Kees Cook]

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

-- 
Kees Cook
Pixel Security

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Arnd Bergmann]

On Sun, Apr 16, 2017 at 9:52 PM, Kees Cook <keescook@chromium.org> wrote:
> Was there a conclusion to this discussion? I didn't see anything
> definitive in the thread...

No definite answer, no. My personal view now is that we should probably
merge the patches I sent, to help those that for one reason or another
use one of those ancient toolchains, but we should not go actively looking
for more problems with those compilers.

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

Thanks for looking these up. This means we need to consider how important
build testing on SLES11 is to us in the long run. The most important scenario
I can think of for anyone would be someone that maintains an embedded
system with an x86 CPU and uses a SLES11 setup to maintain their
own distro.

In this case you typically don't want to modify your environment, but
one might want to upgrade the target kernel, and would suffer if
we break that.

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

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.

      Arnd

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Kees Cook]

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

-- 
Kees Cook
Pixel Security

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Arnd Bergmann]

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.

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

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Kees Cook]

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


-- 
Kees Cook
Pixel Security

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Maciej W. Rozycki]

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.

  Maciej

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Arnd Bergmann]

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

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Geert Uytterhoeven]

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.

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.

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.

BTW, below is the diff I use to avoid an ICE.
After that, it builds and (test)boots fine on ARAnyM ;-)

diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index ec0848fcca02d896..eb75b324ac0ac53d 100644
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -650,13 +650,16 @@ int gfs2_glock_get(struct gfs2_sbd *sdp, u64 number,
                   struct gfs2_glock **glp)
 {
        struct super_block *s = sdp->sd_vfs;
-       struct lm_lockname name = { .ln_number = number,
+       // FIXME Avoid gcc 4.1.2 20061115 (prerelease) (Ubuntu 4.1.1-21) ICE
+       //struct lm_lockname name = { .ln_number = number,
+       struct lm_lockname name = {
                                    .ln_type = glops->go_type,
                                    .ln_sbd = sdp };
        struct gfs2_glock *gl, *tmp = NULL;
        struct address_space *mapping;
        struct kmem_cache *cachep;
        int ret, tries = 0;
+       name.ln_number = number;

        rcu_read_lock();
        gl = rhashtable_lookup_fast(&gl_hash_table, &name, ht_parms);
diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index 86ccc01593937d93..8783b72df5fa3d0c 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -1767,7 +1767,11 @@ static void try_rgrp_unlink(struct gfs2_rgrpd
*rgd, u64 *last_unlinked, u64 skip
        struct gfs2_inode *ip;
        int error;
        int found = 0;
-       struct gfs2_rbm rbm = { .rgd = rgd, .bii = 0, .offset = 0 };
+       // FIXME Avoid gcc 4.1.2 20061115 (prerelease) (Ubuntu 4.1.1-21) ICE
+       // struct gfs2_rbm rbm = { .rgd = rgd, .bii = 0, .offset = 0 };
+       struct gfs2_rbm rbm = { .bii = 0, .offset = 0 };
+       rbm.rgd = rgd;
+

        while (1) {
                down_write(&sdp->sd_log_flush_lock);

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Arnd Bergmann]

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

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Geert Uytterhoeven]

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 at 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

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Arnd Bergmann]

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

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Maciej W. Rozycki]

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.

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

 Huh?

$ git log -1
commit 5a7ad1146caa895ad718a534399e38bd2ba721b7
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Apr 23 16:53:00 2017 -0700

    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.

  Maciej

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Arnd Bergmann]

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

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Geert Uytterhoeven]

Hi Arnd,

On Mon, Apr 24, 2017 at 7:29 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> 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.

If you prefer to consider everyone who's been sleeping in the same room
at one of the Oldenburg Linux meetings as part of my household, that's
fine for me ;-)

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

Mine is also some patched version of 4.1.1, built from Ubuntu sources:

    gcc version 4.1.2 20061115 (prerelease) (Ubuntu 4.1.1-21)

These sources probably even contained the fixes to make gcc-4.1.1
usable on CELL.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Maciej W. Rozycki]

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

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Arnd Bergmann]

On Mon, Apr 24, 2017 at 8:30 PM, Maciej W. Rozycki <macro@linux-mips.org> wrote:
> On Mon, 24 Apr 2017, Arnd Bergmann wrote:
>
>>
>> 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).

Ok.

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

I'd recommend dropping that -Werror from mips and the other few
architectures that have it, or maybe wrapping it in a Kconfig symbol that
is disabled by default. It would also take care of
==> build/mips/bmips_be_defconfig/log <==
cc1: warnings being treated as errors
/git/arm-soc/arch/mips/bmips/setup.c:37: error: integer constant is
too large for 'long' type

As mentioned, we can also turn off the warnings by default and let
Geert turn them on again:

diff --git a/Makefile b/Makefile
index 779302695453..2528f60fb9ab 100644
--- a/Makefile
+++ b/Makefile
@@ -647,8 +647,10 @@ KBUILD_CFLAGS   += -O2
 endif
 endif

-KBUILD_CFLAGS += $(call cc-ifversion, -lt, 0409, \
-                                  $(call
cc-disable-warning,maybe-uninitialized,))
+KBUILD_CFLAGS += $(call cc-ifversion, -lt, 0408, \
+                                 $(call cc-disable-warning,uninitialized, \
+                                 $(call cc-ifversion, -lt, 0409, \
+                                 $(call
cc-disable-warning,maybe-uninitialized,))))

 # Tell gcc to never replace conditional load with a non-conditional one
 KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)


I've built the remaining defconfigs in the meantime (linux-4.11-rc8, gcc-4.1.3,
ARCH=mips) and got 38 builds with warnings and 20 failed builds. There are
at least six different build failures and only one ICE among them (only
in decstation_defconfig). With gcc-4.3 this is only slightly better: 18
failed build, 20 with warnings and 20 without warnings.

With linux-4.3, I saw this failure on 32 defconfigs,
and you fixed that in linux-4.7 with e49d38488515 ("MIPS: MSA: Fix a
link error on `_init_msa_upper' with older GCC"):

arch/mips/built-in.o: In function `enable_restore_fp_context':
traps.c:(.text+0xbefc): undefined reference to `_init_msa_upper'
traps.c:(.text+0xbfc0): undefined reference to `_init_msa_upper'

With gcc-4.9, all mips defconfigs now build without warnings.

For the other architectures in linux-4.11-rc8 can actually build with
sparc-gcc-4.1, afaict this was a bug that impacted all compilers up to
gcc-4.7 and a workaround was added recently. In turn, parisc-gcc-4.1
no longer works on linux-4.11, so we still have only three architectures
that can build their 'defconfig' with the old compiler, plus the majority
of the mips config files.

So while overall I still think that gcc-4.1 is rather broken, it seems that
you have it well under control on both mips and m68k. It's possible
that some other people use patched gcc-4.1 or only build special
configurations on further architectures that I found to be broken
with vanilla toolchains and the regular defconfig.

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.

        Arnd

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Kees Cook]

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

-- 
Kees Cook
Pixel Security

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Geert Uytterhoeven]

On Mon, Apr 24, 2017 at 10:52 PM, Kees Cook <keescook@chromium.org> wrote:
> 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!

+1

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

[Suzuki K Poulose]

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