Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1543377 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6? Arnd Bergmann <arnd@arndb.de> - 2016-12-16 12:10 +0100
    [PATCH 01/13] [HACK] gcc-4.5: avoid  link errors for unused function pointers Arnd Bergmann <arnd@arndb.de> - 2016-12-16 12:10 +0100
    Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6? Arnd Bergmann <arnd@arndb.de> - 2016-12-16 12:20 +0100
    Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6? Geert Uytterhoeven <geert@linux-m68k.org> - 2016-12-16 17:10 +0100
      Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6? Arnd Bergmann <arnd@arndb.de> - 2016-12-16 21:00 +0100
        Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6? Geert Uytterhoeven <geert@linux-m68k.org> - 2016-12-16 21:40 +0100
    Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6? Sebastian Andrzej Siewior <sebastian@breakpoint.cc> - 2016-12-16 18:10 +0100
      Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6? Arnd Bergmann <arnd@arndb.de> - 2016-12-16 23:10 +0100
        Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6? Sebastian Andrzej Siewior <sebastian@breakpoint.cc> - 2016-12-17 12:40 +0100
          Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6? Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-01-02 13:30 +0100
        Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6? Heiko Carstens <heiko.carstens@de.ibm.com> - 2016-12-20 11:00 +0100

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

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

-- 
2.9.0

[toc] | [next] | [standalone]

#1543378 — [PATCH 01/13] [HACK] gcc-4.5: avoid link errors for unused function pointers

gcc versions before 4.6 cannot do dead code elimination across
function pointers, e.g. with a construct like

static int f(void)
{
	return declared_extern_but_undefined_function();
}

static int g(void)
{
	if (0)
		reference_function(&f);
}

which we rely on in lots of places when registering functions,
it results in a link error for
declared_extern_but_undefined_function.

This patch is incomplete and introduces a few other problems
(at least warnings about unused functions), but it shows what
we would have to do in order to address this in the kernel.

The three options forward I see are:

- Declare gcc-4.5 (and prior version) fully supported and
  do proper fixes for the bugs we find.

- Officially declare gcc-4.6 the minimum required version
  for the kernel and remove all existing hacks we have for
  older versions.

- Do nothing: if you use an older gcc version and you run into
  this, you are on your own and can submit a patch for the
  specific problem you find.

At the moment, gcc-3.2 is in theory still supported, but I
found that even gcc-4.2 is almost completely useless these
days at least on ARM.

If we want to keep gcc-4.5 supported, then we can probably
have 4.3 as the minimum version without too many other
workarounds.

Do not apply but feel free to pick out parts of this
patch and submit them if you use old gcc versions and
run into the problems.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-imx/pm-imx5.c          | 20 ++++++++++++++++----
 arch/arm/mach-sa1100/pm.c            |  2 ++
 arch/arm/plat-samsung/pm.c           |  4 ++++
 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 ++++++
 7 files changed, 38 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
index 9424e7f808c7..de912b0a6451 100644
--- a/arch/arm/mach-imx/pm-imx5.c
+++ b/arch/arm/mach-imx/pm-imx5.c
@@ -78,6 +78,7 @@ struct imx5_pm_suspend_data {
 	int suspend_io_count;
 };
 
+#ifdef CONFIG_SOC_IMX53
 static const struct imx5_suspend_io_state imx53_suspend_io_config[] = {
 #define MX53_DSE_HIGHZ_MASK (0x7 << 19)
 	{.offset = 0x584, .clear = MX53_DSE_HIGHZ_MASK}, /* DQM0 */
@@ -104,13 +105,17 @@ static const struct imx5_suspend_io_state imx53_suspend_io_config[] = {
 	/* Controls the CKE signal which is required to leave self refresh */
 	{.offset = 0x720, .clear = MX53_DSE_HIGHZ_MASK, .set = 1 << 19}, /* CTLDS */
 };
+#endif
 
+#ifdef CONFIG_SOC_IMX51
 static const struct imx5_pm_data imx51_pm_data __initconst = {
 	.ccm_addr = 0x73fd4000,
 	.cortex_addr = 0x83fa0000,
 	.gpc_addr = 0x73fd8000,
 };
+#endif
 
+#if defined(CONFIG_SOC_IMX53) && defined(CONFIG_SUSPEND)
 static const struct imx5_pm_data imx53_pm_data __initconst = {
 	.ccm_addr = 0x53fd4000,
 	.cortex_addr = 0x63fa0000,
@@ -127,6 +132,9 @@ static const struct imx5_pm_suspend_data imx53_pm_suspend_data __initconst = {
 };
 
 #define MX5_MAX_SUSPEND_IOSTATE ARRAY_SIZE(imx53_suspend_io_config)
+#else
+#define MX5_MAX_SUSPEND_IOSTATE 0
+#endif
 
 /*
  * This structure is for passing necessary data for low level ocram
@@ -383,6 +391,7 @@ static int __init imx5_suspend_init(const struct imx5_pm_suspend_data *soc_data)
 	return ret;
 }
 
+#if defined(CONFIG_SUSPEND)
 static int __init imx5_pm_common_init(const struct imx5_pm_data *data,
 				      const struct imx5_pm_suspend_data *sdata)
 {
@@ -420,15 +429,18 @@ static int __init imx5_pm_common_init(const struct imx5_pm_data *data,
 
 	return 0;
 }
+#endif
 
 void __init imx51_pm_init(void)
 {
-	if (IS_ENABLED(CONFIG_SOC_IMX51))
-		imx5_pm_common_init(&imx51_pm_data, NULL);
+#if defined(CONFIG_SOC_IMX51) && defined(CONFIG_SUSPEND)
+	imx5_pm_common_init(&imx51_pm_data, NULL);
+#endif
 }
 
 void __init imx53_pm_init(void)
 {
-	if (IS_ENABLED(CONFIG_SOC_IMX53))
-		imx5_pm_common_init(&imx53_pm_data, &imx53_pm_suspend_data);
+#if defined(CONFIG_SOC_IMX53) && defined(CONFIG_SUSPEND)
+	imx5_pm_common_init(&imx53_pm_data, &imx53_pm_suspend_data);
+#endif
 }
diff --git a/arch/arm/mach-sa1100/pm.c b/arch/arm/mach-sa1100/pm.c
index 34853d5dfda2..cb896dc97030 100644
--- a/arch/arm/mach-sa1100/pm.c
+++ b/arch/arm/mach-sa1100/pm.c
@@ -121,6 +121,8 @@ static const struct platform_suspend_ops sa11x0_pm_ops = {
 
 int __init sa11x0_pm_init(void)
 {
+#ifdef CONFIG_SUSPEND
 	suspend_set_ops(&sa11x0_pm_ops);
+#endif
 	return 0;
 }
diff --git a/arch/arm/plat-samsung/pm.c b/arch/arm/plat-samsung/pm.c
index d7803b434732..264c538a3ab8 100644
--- a/arch/arm/plat-samsung/pm.c
+++ b/arch/arm/plat-samsung/pm.c
@@ -71,6 +71,7 @@ int (*pm_cpu_sleep)(unsigned long);
  * central control for sleep/resume process
 */
 
+#ifdef CONFIG_SUSPEND
 static int s3c_pm_enter(suspend_state_t state)
 {
 	int ret;
@@ -194,11 +195,14 @@ static const struct platform_suspend_ops s3c_pm_ops = {
  * from the board specific initialisation if the board supports
  * it.
 */
+#endif
 
 int __init s3c_pm_init(void)
 {
+#ifdef CONFIG_SUSPEND
 	printk("S3C Power Management, Copyright 2004 Simtec Electronics\n");
 
 	suspend_set_ops(&s3c_pm_ops);
+#endif
 	return 0;
 }
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 3f24aeb48c0e..e9f0543cb30a 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -184,8 +184,10 @@ static int ti_am335x_xbar_probe(struct platform_device *pdev)
 	for (i = 0; i < xbar->dma_requests; i++)
 		ti_am335x_xbar_write(xbar->iomem, i, 0);
 
+#ifdef CONFIG_DMA_OF
 	ret = of_dma_router_register(node, ti_am335x_xbar_route_allocate,
 				     &xbar->dmarouter);
+#endif
 
 	return ret;
 }
@@ -414,8 +416,10 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
 			ti_dra7_xbar_write(xbar->iomem, i, xbar->safe_val);
 	}
 
+#ifdef CONFIG_DMA_OF
 	ret = of_dma_router_register(node, ti_dra7_xbar_route_allocate,
 				     &xbar->dmarouter);
+#endif
 	if (ret) {
 		/* Restore the defaults for the crossbar */
 		for (i = 0; i < xbar->dma_requests; i++) {
diff --git a/drivers/firmware/psci_checker.c b/drivers/firmware/psci_checker.c
index 44bdb78f837b..37c5c873c5ec 100644
--- a/drivers/firmware/psci_checker.c
+++ b/drivers/firmware/psci_checker.c
@@ -273,6 +273,9 @@ static int suspend_test_thread(void *arg)
 	struct timer_list wakeup_timer =
 		TIMER_INITIALIZER(dummy_callback, 0, 0);
 
+	if (!IS_ENABLED(CONFIG_CPU_IDLE))
+		return -ENXIO;
+
 	/* Wait for the main thread to give the start signal. */
 	wait_for_completion(&suspend_threads_started);
 
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index c15756d7bf7f..b2a658aa9a83 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -615,6 +615,9 @@ static irqreturn_t exynos_ts_isr(int irq, void *dev_id)
 	bool pressed;
 	int ret;
 
+	if (!IS_REACHABLE(CONFIG_INPUT))
+		return IRQ_HANDLED;
+
 	while (info->input->users) {
 		ret = exynos_read_s3c64xx_ts(dev, &x, &y);
 		if (ret == -ETIMEDOUT)
diff --git a/drivers/net/ethernet/via/via-rhine.c b/drivers/net/ethernet/via/via-rhine.c
index ba5c54249055..6b45401ff149 100644
--- a/drivers/net/ethernet/via/via-rhine.c
+++ b/drivers/net/ethernet/via/via-rhine.c
@@ -2580,6 +2580,7 @@ static SIMPLE_DEV_PM_OPS(rhine_pm_ops, rhine_suspend, rhine_resume);
 
 #endif /* !CONFIG_PM_SLEEP */
 
+#ifdef CONFIG_PCI
 static struct pci_driver rhine_driver_pci = {
 	.name		= DRV_NAME,
 	.id_table	= rhine_pci_tbl,
@@ -2588,6 +2589,7 @@ static struct pci_driver rhine_driver_pci = {
 	.shutdown	= rhine_shutdown_pci,
 	.driver.pm	= RHINE_PM_OPS,
 };
+#endif
 
 static struct platform_driver rhine_driver_platform = {
 	.probe		= rhine_init_one_platform,
@@ -2633,7 +2635,9 @@ static int __init rhine_init(void)
 	else if (avoid_D3)
 		pr_info("avoid_D3 set\n");
 
+#ifdef CONFIG_PCI
 	ret_pci = pci_register_driver(&rhine_driver_pci);
+#endif
 	ret_platform = platform_driver_register(&rhine_driver_platform);
 	if ((ret_pci < 0) && (ret_platform < 0))
 		return ret_pci;
@@ -2645,7 +2649,9 @@ static int __init rhine_init(void)
 static void __exit rhine_cleanup(void)
 {
 	platform_driver_unregister(&rhine_driver_platform);
+#ifdef CONFIG_PCI
 	pci_unregister_driver(&rhine_driver_pci);
+#endif
 }
 
 
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

#1543386

[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(-)
> 
> 

[toc] | [prev] | [next] | [standalone]

#1543552

Hi Arnd,

On Fri, Dec 16, 2016 at 11:56 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> 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.

If you start with that activity now, there's indeed a massive amount of
warnings to look into.
However, I've been build testing various configs with m68k-linux-gnu-gcc-4.1.2
and looking at the compiler warnings for years, so I only have to look
at new warnings.

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

[toc] | [prev] | [next] | [standalone]

#1543722

On Friday, December 16, 2016 4:54:33 PM CET Geert Uytterhoeven wrote:
> Hi Arnd,
> 
> On Fri, Dec 16, 2016 at 11:56 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > 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.
> 
> If you start with that activity now, there's indeed a massive amount of
> warnings to look into.
> However, I've been build testing various configs with m68k-linux-gnu-gcc-4.1.2
> and looking at the compiler warnings for years, so I only have to look
> at new warnings.

What's the reason for sticking with gcc-4.1? Does this actually work better
for you than a more recent version, or is it just whatever you installed
when you started the build testing?

	Arnd

[toc] | [prev] | [next] | [standalone]

#1543736

Hi Arnd,

On Fri, Dec 16, 2016 at 8:58 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday, December 16, 2016 4:54:33 PM CET Geert Uytterhoeven wrote:
>> On Fri, Dec 16, 2016 at 11:56 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > 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.
>>
>> If you start with that activity now, there's indeed a massive amount of
>> warnings to look into.
>> However, I've been build testing various configs with m68k-linux-gnu-gcc-4.1.2
>> and looking at the compiler warnings for years, so I only have to look
>> at new warnings.
>
> What's the reason for sticking with gcc-4.1? Does this actually work better
> for you than a more recent version, or is it just whatever you installed
> when you started the build testing?

It's just the cross compiler I built .debs of a long time ago.
As long as it works, I see no reason to upgrade, especially as long as I see
warnings for bugs that no one else is seeing. But lately you started beating
me with newer gccs ;-)

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

[toc] | [prev] | [next] | [standalone]

#1543597

On 2016-12-16 11:56:21 [+0100], Arnd Bergmann 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.

It this min gcc thingy ARM only?
The current minimium (documented) is gcc v3.2. With the -fno-PIE patches
I was going to raise the bar to at least v3.4 but did not get around to
it yet. hpa said that everything < 3.4 is broken on x86 [0].
Gert is getting code compiled on gcc v4.1 not sure if it is some kind of
gcc limitation or just for fun.
Unless people are stuck with some enterprise distro I don't see a reason
why one should not try a gcc-4.6 which is 5 years old. I had problems to
verify that the current kernel compiles with gcc v3.2 on x86 (it did
with a bunch of warnings with gcc 3.4 and booted).

[0] https://lkml.kernel.org/r/63c356a8-58a3-bc7e-88db-5c8071db15e1@zytor.com
> 	Arnd

Sebastian

[toc] | [prev] | [next] | [standalone]

#1543776

On Friday, December 16, 2016 6:00:43 PM CET Sebastian Andrzej Siewior wrote:
> On 2016-12-16 11:56:21 [+0100], Arnd Bergmann 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.
> 
> It this min gcc thingy ARM only?

This is part of the question that I'm trying to figure out myself.

Clearly having the same minimum version across all architectures simplifies
things a lot, because many of the bugs in old versions are architecture
independent. Then again, some architectures implicitly require a new version
because an old one never existed (e.g. arm64 or risc-v), while some other
architectures may require an old version.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1543956

On 2016-12-16 23:00:27 [+0100], Arnd Bergmann wrote:
> On Friday, December 16, 2016 6:00:43 PM CET Sebastian Andrzej Siewior wrote:
> > On 2016-12-16 11:56:21 [+0100], Arnd Bergmann 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.
> > 
> > It this min gcc thingy ARM only?
> 
> This is part of the question that I'm trying to figure out myself.
> 
> Clearly having the same minimum version across all architectures simplifies
> things a lot, because many of the bugs in old versions are architecture
> independent. 

agreed.

> Then again, some architectures implicitly require a new version
> because an old one never existed (e.g. arm64 or risc-v), while some other
> architectures may require an old version.

A new version is understandable. But why is an old version required?
One thing is an enterprise distro that is "current" or "supported" and still
stuck with gcc 4.1 because that is the version they decided to include in
their release. This is sad. But you might want to ask yourself why you want
the latest kernel but an old gcc / binutils.

If you have an architecture that compiles with gcc v4.1 and not with gcc
latest stable / trunk then it is a sign that this port is not supported
properly / not heatly. One thing is something like avr32 which is not part of
upstream gcc due to some legal reason (that was my understanding a few years
ago). It might get to a problem for them once large parts of userland switch
to a later C++ standard which is gcc-5+.

> 	Arnd

Sebastian

[toc] | [prev] | [next] | [standalone]

#1549143

On Sat, Dec 17, 2016 at 12:29:50PM +0100, Sebastian Andrzej Siewior wrote:
> A new version is understandable. But why is an old version required?
> One thing is an enterprise distro that is "current" or "supported" and still
> stuck with gcc 4.1 because that is the version they decided to include in
> their release. This is sad. But you might want to ask yourself why you want
> the latest kernel but an old gcc / binutils.

To help isolate changes.

If you constantly upgrade everything, how do you bug hunt for a breakage?
How do you know whether it's created by the kernel, or by (eg) a later
version of gcc miscompiling the kernel.  You have a large amount of code
to start bug hunting through.

Sticking with particular tool versions long-term means that you build up
confidence in it - yes, sure, latent bugs exist, but it's easier to
bug hunt if you aren't constantly suspecting that your tools might be
broken.

For example, I build kernels with:

		gcc		binutils		built on
32-bit ARM	4.7.4		2.25			April/May 2015
64-bit ARM	4.9.2		2.25.51.20150219	Feb/April 2015

I'm not anticipating upgrading them for some time yet - the only one
which may get upgraded is the 64-bit binutils since later kernels now
complain about a missing errata workaround in that toolchain version.

I do still have some older toolchains around on some of my ARM boxes
though, even a GCC 3 version with ARM TLS support for faster builds!

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [next] | [standalone]

#1545017

On Fri, Dec 16, 2016 at 11:00:27PM +0100, Arnd Bergmann wrote:
> On Friday, December 16, 2016 6:00:43 PM CET Sebastian Andrzej Siewior wrote:
> > On 2016-12-16 11:56:21 [+0100], Arnd Bergmann 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.
> > 
> > It this min gcc thingy ARM only?
> 
> This is part of the question that I'm trying to figure out myself.
> 
> Clearly having the same minimum version across all architectures simplifies
> things a lot, because many of the bugs in old versions are architecture
> independent. Then again, some architectures implicitly require a new version
> because an old one never existed (e.g. arm64 or risc-v), while some other
> architectures may require an old version.

FWIW, s390 requires gcc 4.3 or newer since two years already. For older
compilers we enforce a compile error (see arch/s390/kernel/asm-offsets.c).

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web