[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]

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

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

[Arnd Bergmann]

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

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

[Arnd Bergmann]

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

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

[Arnd Bergmann]

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

[PATCH 02/13] KVM: arm: fix gcc-4.5 build

[Arnd Bergmann]

Old gcc versions cannot used named initializers for anonymous
unions, leading to a build failure here. This replaces the anonymous
union with a named one, which allows us to build with at least gcc-4.3
through 4.5. Versions 4.6 and higher are fine without this.

virt/kvm/arm/vgic/vgic-mmio-v2.c:295: error: unknown field 'read' specified in initializer
virt/kvm/arm/vgic/vgic-mmio-v2.c:295: warning: missing braces around initializer
virt/kvm/arm/vgic/vgic-mmio-v2.c:295: warning: (near initialization for 'vgic_v2_dist_registers[0].<anonymous>')
virt/kvm/arm/vgic/vgic-mmio-v2.c:295: error: unknown field 'write' specified in initializer
virt/kvm/arm/vgic/vgic-mmio-v2.c:298: error: unknown field 'read' specified in initializer

Fixes: 59c5ab40989a ("KVM: arm64: vgic-its: Introduce ITS emulation file with MMIO framework")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 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 ++++++------
 4 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
index 8c2b3cdcb2c5..922d820e2646 100644
--- a/virt/kvm/arm/vgic/vgic-its.c
+++ b/virt/kvm/arm/vgic/vgic-its.c
@@ -1292,8 +1292,8 @@ static void vgic_mmio_write_its_baser(struct kvm *kvm,
 	.reg_offset = off,					\
 	.len = length,						\
 	.access_flags = acc,					\
-	.its_read = rd,						\
-	.its_write = wr,					\
+	.r.its_read = rd,						\
+	.w.its_write = wr,					\
 }
 
 static void its_mmio_write_wi(struct kvm *kvm, struct vgic_its *its,
diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
index 50f42f0f8c4f..aa31110e4ebd 100644
--- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
+++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
@@ -362,15 +362,15 @@ static void vgic_mmio_write_pendbase(struct kvm_vcpu *vcpu,
 		.bits_per_irq = bpi,					\
 		.len = (bpi * VGIC_NR_PRIVATE_IRQS) / 8,		\
 		.access_flags = acc,					\
-		.read = vgic_mmio_read_raz,				\
-		.write = vgic_mmio_write_wi,				\
+		.r.read = vgic_mmio_read_raz,				\
+		.w.write = vgic_mmio_write_wi,				\
 	}, {								\
 		.reg_offset = off + (bpi * VGIC_NR_PRIVATE_IRQS) / 8,	\
 		.bits_per_irq = bpi,					\
 		.len = (bpi * (1024 - VGIC_NR_PRIVATE_IRQS)) / 8,	\
 		.access_flags = acc,					\
-		.read = rd,						\
-		.write = wr,						\
+		.r.read = rd,						\
+		.w.write = wr,						\
 	}
 
 static const struct vgic_register_region vgic_v3_dist_registers[] = {
diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
index ebe1b9fa3c4d..6690922bc6b0 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.c
+++ b/virt/kvm/arm/vgic/vgic-mmio.c
@@ -500,16 +500,16 @@ static int dispatch_mmio_read(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
 
 	switch (iodev->iodev_type) {
 	case IODEV_CPUIF:
-		data = region->read(vcpu, addr, len);
+		data = region->r.read(vcpu, addr, len);
 		break;
 	case IODEV_DIST:
-		data = region->read(vcpu, addr, len);
+		data = region->r.read(vcpu, addr, len);
 		break;
 	case IODEV_REDIST:
-		data = region->read(iodev->redist_vcpu, addr, len);
+		data = region->r.read(iodev->redist_vcpu, addr, len);
 		break;
 	case IODEV_ITS:
-		data = region->its_read(vcpu->kvm, iodev->its, addr, len);
+		data = region->r.its_read(vcpu->kvm, iodev->its, addr, len);
 		break;
 	}
 
@@ -531,16 +531,16 @@ static int dispatch_mmio_write(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
 
 	switch (iodev->iodev_type) {
 	case IODEV_CPUIF:
-		region->write(vcpu, addr, len, data);
+		region->w.write(vcpu, addr, len, data);
 		break;
 	case IODEV_DIST:
-		region->write(vcpu, addr, len, data);
+		region->w.write(vcpu, addr, len, data);
 		break;
 	case IODEV_REDIST:
-		region->write(iodev->redist_vcpu, addr, len, data);
+		region->w.write(iodev->redist_vcpu, addr, len, data);
 		break;
 	case IODEV_ITS:
-		region->its_write(vcpu->kvm, iodev->its, addr, len, data);
+		region->w.its_write(vcpu->kvm, iodev->its, addr, len, data);
 		break;
 	}
 
diff --git a/virt/kvm/arm/vgic/vgic-mmio.h b/virt/kvm/arm/vgic/vgic-mmio.h
index 84961b4e4422..7f7da7239612 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.h
+++ b/virt/kvm/arm/vgic/vgic-mmio.h
@@ -26,14 +26,14 @@ struct vgic_register_region {
 				      unsigned int len);
 		unsigned long (*its_read)(struct kvm *kvm, struct vgic_its *its,
 					  gpa_t addr, unsigned int len);
-	};
+	} r;
 	union {
 		void (*write)(struct kvm_vcpu *vcpu, gpa_t addr,
 			      unsigned int len, unsigned long val);
 		void (*its_write)(struct kvm *kvm, struct vgic_its *its,
 				  gpa_t addr, unsigned int len,
 				  unsigned long val);
-	};
+	} w;
 };
 
 extern struct kvm_io_device_ops kvm_io_gic_ops;
@@ -72,8 +72,8 @@ extern struct kvm_io_device_ops kvm_io_gic_ops;
 		.bits_per_irq = bpi,					\
 		.len = bpi * 1024 / 8,					\
 		.access_flags = acc,					\
-		.read = rd,						\
-		.write = wr,						\
+		.r.read = rd,						\
+		.w.write = wr,						\
 	}
 
 #define REGISTER_DESC_WITH_LENGTH(off, rd, wr, length, acc)		\
@@ -82,8 +82,8 @@ extern struct kvm_io_device_ops kvm_io_gic_ops;
 		.bits_per_irq = 0,					\
 		.len = length,						\
 		.access_flags = acc,					\
-		.read = rd,						\
-		.write = wr,						\
+		.r.read = rd,						\
+		.w.write = wr,						\
 	}
 
 int kvm_vgic_register_mmio_region(struct kvm *kvm, struct kvm_vcpu *vcpu,
-- 
2.9.0

[PATCH 02/13] KVM: arm: fix gcc-4.5 build

[Arnd Bergmann]

Old gcc versions cannot used named initializers for anonymous
unions, leading to a build failure here. This replaces the anonymous
union with a named one, which allows us to build with at least gcc-4.3
through 4.5. Versions 4.6 and higher are fine without this.

virt/kvm/arm/vgic/vgic-mmio-v2.c:295: error: unknown field 'read' specified in initializer
virt/kvm/arm/vgic/vgic-mmio-v2.c:295: warning: missing braces around initializer
virt/kvm/arm/vgic/vgic-mmio-v2.c:295: warning: (near initialization for 'vgic_v2_dist_registers[0].<anonymous>')
virt/kvm/arm/vgic/vgic-mmio-v2.c:295: error: unknown field 'write' specified in initializer
virt/kvm/arm/vgic/vgic-mmio-v2.c:298: error: unknown field 'read' specified in initializer

Fixes: 59c5ab40989a ("KVM: arm64: vgic-its: Introduce ITS emulation file with MMIO framework")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 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 ++++++------
 4 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
index 8c2b3cdcb2c5..922d820e2646 100644
--- a/virt/kvm/arm/vgic/vgic-its.c
+++ b/virt/kvm/arm/vgic/vgic-its.c
@@ -1292,8 +1292,8 @@ static void vgic_mmio_write_its_baser(struct kvm *kvm,
 	.reg_offset = off,					\
 	.len = length,						\
 	.access_flags = acc,					\
-	.its_read = rd,						\
-	.its_write = wr,					\
+	.r.its_read = rd,						\
+	.w.its_write = wr,					\
 }
 
 static void its_mmio_write_wi(struct kvm *kvm, struct vgic_its *its,
diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
index 50f42f0f8c4f..aa31110e4ebd 100644
--- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
+++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
@@ -362,15 +362,15 @@ static void vgic_mmio_write_pendbase(struct kvm_vcpu *vcpu,
 		.bits_per_irq = bpi,					\
 		.len = (bpi * VGIC_NR_PRIVATE_IRQS) / 8,		\
 		.access_flags = acc,					\
-		.read = vgic_mmio_read_raz,				\
-		.write = vgic_mmio_write_wi,				\
+		.r.read = vgic_mmio_read_raz,				\
+		.w.write = vgic_mmio_write_wi,				\
 	}, {								\
 		.reg_offset = off + (bpi * VGIC_NR_PRIVATE_IRQS) / 8,	\
 		.bits_per_irq = bpi,					\
 		.len = (bpi * (1024 - VGIC_NR_PRIVATE_IRQS)) / 8,	\
 		.access_flags = acc,					\
-		.read = rd,						\
-		.write = wr,						\
+		.r.read = rd,						\
+		.w.write = wr,						\
 	}
 
 static const struct vgic_register_region vgic_v3_dist_registers[] = {
diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
index ebe1b9fa3c4d..6690922bc6b0 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.c
+++ b/virt/kvm/arm/vgic/vgic-mmio.c
@@ -500,16 +500,16 @@ static int dispatch_mmio_read(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
 
 	switch (iodev->iodev_type) {
 	case IODEV_CPUIF:
-		data = region->read(vcpu, addr, len);
+		data = region->r.read(vcpu, addr, len);
 		break;
 	case IODEV_DIST:
-		data = region->read(vcpu, addr, len);
+		data = region->r.read(vcpu, addr, len);
 		break;
 	case IODEV_REDIST:
-		data = region->read(iodev->redist_vcpu, addr, len);
+		data = region->r.read(iodev->redist_vcpu, addr, len);
 		break;
 	case IODEV_ITS:
-		data = region->its_read(vcpu->kvm, iodev->its, addr, len);
+		data = region->r.its_read(vcpu->kvm, iodev->its, addr, len);
 		break;
 	}
 
@@ -531,16 +531,16 @@ static int dispatch_mmio_write(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
 
 	switch (iodev->iodev_type) {
 	case IODEV_CPUIF:
-		region->write(vcpu, addr, len, data);
+		region->w.write(vcpu, addr, len, data);
 		break;
 	case IODEV_DIST:
-		region->write(vcpu, addr, len, data);
+		region->w.write(vcpu, addr, len, data);
 		break;
 	case IODEV_REDIST:
-		region->write(iodev->redist_vcpu, addr, len, data);
+		region->w.write(iodev->redist_vcpu, addr, len, data);
 		break;
 	case IODEV_ITS:
-		region->its_write(vcpu->kvm, iodev->its, addr, len, data);
+		region->w.its_write(vcpu->kvm, iodev->its, addr, len, data);
 		break;
 	}
 
diff --git a/virt/kvm/arm/vgic/vgic-mmio.h b/virt/kvm/arm/vgic/vgic-mmio.h
index 84961b4e4422..7f7da7239612 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.h
+++ b/virt/kvm/arm/vgic/vgic-mmio.h
@@ -26,14 +26,14 @@ struct vgic_register_region {
 				      unsigned int len);
 		unsigned long (*its_read)(struct kvm *kvm, struct vgic_its *its,
 					  gpa_t addr, unsigned int len);
-	};
+	} r;
 	union {
 		void (*write)(struct kvm_vcpu *vcpu, gpa_t addr,
 			      unsigned int len, unsigned long val);
 		void (*its_write)(struct kvm *kvm, struct vgic_its *its,
 				  gpa_t addr, unsigned int len,
 				  unsigned long val);
-	};
+	} w;
 };
 
 extern struct kvm_io_device_ops kvm_io_gic_ops;
@@ -72,8 +72,8 @@ extern struct kvm_io_device_ops kvm_io_gic_ops;
 		.bits_per_irq = bpi,					\
 		.len = bpi * 1024 / 8,					\
 		.access_flags = acc,					\
-		.read = rd,						\
-		.write = wr,						\
+		.r.read = rd,						\
+		.w.write = wr,						\
 	}
 
 #define REGISTER_DESC_WITH_LENGTH(off, rd, wr, length, acc)		\
@@ -82,8 +82,8 @@ extern struct kvm_io_device_ops kvm_io_gic_ops;
 		.bits_per_irq = 0,					\
 		.len = length,						\
 		.access_flags = acc,					\
-		.read = rd,						\
-		.write = wr,						\
+		.r.read = rd,						\
+		.w.write = wr,						\
 	}
 
 int kvm_vgic_register_mmio_region(struct kvm *kvm, struct kvm_vcpu *vcpu,
-- 
2.9.0

Re: [PATCH 02/13] KVM: arm: fix gcc-4.5 build

[Christoffer Dall]

On Fri, Dec 16, 2016 at 11:56:23AM +0100, Arnd Bergmann wrote:
> Old gcc versions cannot used named initializers for anonymous
> unions, leading to a build failure here. This replaces the anonymous
> union with a named one, which allows us to build with at least gcc-4.3
> through 4.5. Versions 4.6 and higher are fine without this.
> 
> virt/kvm/arm/vgic/vgic-mmio-v2.c:295: error: unknown field 'read' specified in initializer
> virt/kvm/arm/vgic/vgic-mmio-v2.c:295: warning: missing braces around initializer
> virt/kvm/arm/vgic/vgic-mmio-v2.c:295: warning: (near initialization for 'vgic_v2_dist_registers[0].<anonymous>')
> virt/kvm/arm/vgic/vgic-mmio-v2.c:295: error: unknown field 'write' specified in initializer
> virt/kvm/arm/vgic/vgic-mmio-v2.c:298: error: unknown field 'read' specified in initializer
> 
> Fixes: 59c5ab40989a ("KVM: arm64: vgic-its: Introduce ITS emulation file with MMIO framework")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

If this series is moving ahead, I have no problems with this patch:

Acked-by: Christoffer Dall <christoffer.dall@linaro.org>

Re: [PATCH 02/13] KVM: arm: fix gcc-4.5 build

[Christoffer Dall]

On Fri, Dec 16, 2016 at 11:56:23AM +0100, Arnd Bergmann wrote:
> Old gcc versions cannot used named initializers for anonymous
> unions, leading to a build failure here. This replaces the anonymous
> union with a named one, which allows us to build with at least gcc-4.3
> through 4.5. Versions 4.6 and higher are fine without this.
> 
> virt/kvm/arm/vgic/vgic-mmio-v2.c:295: error: unknown field 'read' specified in initializer
> virt/kvm/arm/vgic/vgic-mmio-v2.c:295: warning: missing braces around initializer
> virt/kvm/arm/vgic/vgic-mmio-v2.c:295: warning: (near initialization for 'vgic_v2_dist_registers[0].<anonymous>')
> virt/kvm/arm/vgic/vgic-mmio-v2.c:295: error: unknown field 'write' specified in initializer
> virt/kvm/arm/vgic/vgic-mmio-v2.c:298: error: unknown field 'read' specified in initializer
> 
> Fixes: 59c5ab40989a ("KVM: arm64: vgic-its: Introduce ITS emulation file with MMIO framework")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

If this series is moving ahead, I have no problems with this patch:

Acked-by: Christoffer Dall <christoffer.dall@linaro.org>

[PATCH 03/13] ARM: div64: fix building with gcc-4.5 and lower

[Arnd Bergmann]

drivers/media/dvb-frontends/s921.c: In function 's921_pll_tune':
arch/arm/include/asm/div64.h:109: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
arch/arm/include/asm/div64.h:127: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
arch/arm/include/asm/div64.h:109: error: 'asm' operand has impossible constraints
arch/arm/include/asm/div64.h:127: error: 'asm' operand has impossible constraints
scripts/Makefile.build:299: recipe for target 'drivers/media/dvb-frontends/s921.o' failed

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/include/asm/div64.h | 17 +++--------------
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/arch/arm/include/asm/div64.h b/arch/arm/include/asm/div64.h
index 7ca0c613c33b..e1c8d4a58797 100644
--- a/arch/arm/include/asm/div64.h
+++ b/arch/arm/include/asm/div64.h
@@ -66,27 +66,16 @@ static inline uint32_t __div64_32(uint64_t *n, uint32_t base)
  */
 #define do_div(n, base) __div64_32(&(n), base)
 
-#elif defined(CONFIG_CPU_32v3)
+#elif GCC_VERSION < 40600
 
 /*
- * modern compiler versions (>= gcc-4.9) tend to misoptimize
- * the code for ARMv3, and this is not getting fixed any more.
+ * gcc-4.4 and gcc-4.5 tend to run out of registers in their
+ * register allocation in some functions
  */
 #define do_div(n, base) __div64_32(&(n), base)
 
 #else
 
-/*
- * gcc versions earlier than 4.0 are simply too problematic for the
- * __div64_const32() code in asm-generic/div64.h. First there is
- * gcc PR 15089 that tend to trig on more complex constructs, spurious
- * .global __udivsi3 are inserted even if none of those symbols are
- * referenced in the generated code, and those gcc versions are not able
- * to do constant propagation on long long values anyway.
- */
-
-#define __div64_const32_is_OK (__GNUC__ >= 4)
-
 static inline uint64_t __arch_xprod_64(uint64_t m, uint64_t n, bool bias)
 {
 	unsigned long long res;
-- 
2.9.0

[PATCH 03/13] ARM: div64: fix building with gcc-4.5 and lower

[Arnd Bergmann]

drivers/media/dvb-frontends/s921.c: In function 's921_pll_tune':
arch/arm/include/asm/div64.h:109: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
arch/arm/include/asm/div64.h:127: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
arch/arm/include/asm/div64.h:109: error: 'asm' operand has impossible constraints
arch/arm/include/asm/div64.h:127: error: 'asm' operand has impossible constraints
scripts/Makefile.build:299: recipe for target 'drivers/media/dvb-frontends/s921.o' failed

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/include/asm/div64.h | 17 +++--------------
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/arch/arm/include/asm/div64.h b/arch/arm/include/asm/div64.h
index 7ca0c613c33b..e1c8d4a58797 100644
--- a/arch/arm/include/asm/div64.h
+++ b/arch/arm/include/asm/div64.h
@@ -66,27 +66,16 @@ static inline uint32_t __div64_32(uint64_t *n, uint32_t base)
  */
 #define do_div(n, base) __div64_32(&(n), base)
 
-#elif defined(CONFIG_CPU_32v3)
+#elif GCC_VERSION < 40600
 
 /*
- * modern compiler versions (>= gcc-4.9) tend to misoptimize
- * the code for ARMv3, and this is not getting fixed any more.
+ * gcc-4.4 and gcc-4.5 tend to run out of registers in their
+ * register allocation in some functions
  */
 #define do_div(n, base) __div64_32(&(n), base)
 
 #else
 
-/*
- * gcc versions earlier than 4.0 are simply too problematic for the
- * __div64_const32() code in asm-generic/div64.h. First there is
- * gcc PR 15089 that tend to trig on more complex constructs, spurious
- * .global __udivsi3 are inserted even if none of those symbols are
- * referenced in the generated code, and those gcc versions are not able
- * to do constant propagation on long long values anyway.
- */
-
-#define __div64_const32_is_OK (__GNUC__ >= 4)
-
 static inline uint64_t __arch_xprod_64(uint64_t m, uint64_t n, bool bias)
 {
 	unsigned long long res;
-- 
2.9.0

[PATCH 04/13] vfio-pci: use 32-bit comparisons for register address for gcc-4.5

[Arnd Bergmann]

Using ancient compilers (gcc-4.5 or older) on ARM, we get a link
failure with the vfio-pci driver:

ERROR: "__aeabi_lcmp" [drivers/vfio/pci/vfio-pci.ko] undefined!

The reason is that the compiler tries to do a comparison of
a 64-bit range. This changes it to convert to a 32-bit number
explicitly first, as newer compilers do for themselves.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/vfio/pci/vfio_pci_rdwr.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
index 5ffd1d9ad4bd..357243d76f10 100644
--- a/drivers/vfio/pci/vfio_pci_rdwr.c
+++ b/drivers/vfio/pci/vfio_pci_rdwr.c
@@ -193,7 +193,10 @@ ssize_t vfio_pci_vga_rw(struct vfio_pci_device *vdev, char __user *buf,
 	if (!vdev->has_vga)
 		return -EINVAL;
 
-	switch (pos) {
+	if (pos > 0xbfffful)
+		return -EINVAL;
+
+	switch ((u32)pos) {
 	case 0xa0000 ... 0xbffff:
 		count = min(count, (size_t)(0xc0000 - pos));
 		iomem = ioremap_nocache(0xa0000, 0xbffff - 0xa0000 + 1);
-- 
2.9.0

[PATCH 04/13] vfio-pci: use 32-bit comparisons for register address for gcc-4.5

[Arnd Bergmann]

Using ancient compilers (gcc-4.5 or older) on ARM, we get a link
failure with the vfio-pci driver:

ERROR: "__aeabi_lcmp" [drivers/vfio/pci/vfio-pci.ko] undefined!

The reason is that the compiler tries to do a comparison of
a 64-bit range. This changes it to convert to a 32-bit number
explicitly first, as newer compilers do for themselves.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/vfio/pci/vfio_pci_rdwr.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
index 5ffd1d9ad4bd..357243d76f10 100644
--- a/drivers/vfio/pci/vfio_pci_rdwr.c
+++ b/drivers/vfio/pci/vfio_pci_rdwr.c
@@ -193,7 +193,10 @@ ssize_t vfio_pci_vga_rw(struct vfio_pci_device *vdev, char __user *buf,
 	if (!vdev->has_vga)
 		return -EINVAL;
 
-	switch (pos) {
+	if (pos > 0xbfffful)
+		return -EINVAL;
+
+	switch ((u32)pos) {
 	case 0xa0000 ... 0xbffff:
 		count = min(count, (size_t)(0xc0000 - pos));
 		iomem = ioremap_nocache(0xa0000, 0xbffff - 0xa0000 + 1);
-- 
2.9.0

Re: [PATCH 04/13] vfio-pci: use 32-bit comparisons for register address for gcc-4.5

[Alex Williamson]

On Fri, 16 Dec 2016 11:56:25 +0100
Arnd Bergmann <arnd@arndb.de> wrote:

> Using ancient compilers (gcc-4.5 or older) on ARM, we get a link
> failure with the vfio-pci driver:
> 
> ERROR: "__aeabi_lcmp" [drivers/vfio/pci/vfio-pci.ko] undefined!
> 
> The reason is that the compiler tries to do a comparison of
> a 64-bit range. This changes it to convert to a 32-bit number
> explicitly first, as newer compilers do for themselves.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/vfio/pci/vfio_pci_rdwr.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
> index 5ffd1d9ad4bd..357243d76f10 100644
> --- a/drivers/vfio/pci/vfio_pci_rdwr.c
> +++ b/drivers/vfio/pci/vfio_pci_rdwr.c
> @@ -193,7 +193,10 @@ ssize_t vfio_pci_vga_rw(struct vfio_pci_device *vdev, char __user *buf,
>  	if (!vdev->has_vga)
>  		return -EINVAL;
>  
> -	switch (pos) {
> +	if (pos > 0xbfffful)
> +		return -EINVAL;
> +
> +	switch ((u32)pos) {
>  	case 0xa0000 ... 0xbffff:
>  		count = min(count, (size_t)(0xc0000 - pos));
>  		iomem = ioremap_nocache(0xa0000, 0xbffff - 0xa0000 + 1);

Acked-by: Alex Williamson <alex.williamson@redhat.com>

Would you like me to pull this one patch in through the vfio tree?
Thanks,

Alex

Re: [PATCH 04/13] vfio-pci: use 32-bit comparisons for register address for gcc-4.5

[Arnd Bergmann]

On Friday, December 16, 2016 8:30:56 AM CET Alex Williamson wrote:
> 
> Acked-by: Alex Williamson <alex.williamson@redhat.com>
> 
> Would you like me to pull this one patch in through the vfio tree?
> Thanks,

If you think the patch is appropriate, please merge it.

I originally just posted this as illustration to raise the
question of whether we actually want to support gcc-4.5,
from the feedback so far it does seem like the answer is yes,
and we will need it.

	Arnd

[PATCH 05/13] clk: pxa: fix gcc-4.4 build

[Arnd Bergmann]

With gcc-4.4 and earlier, the asm statement must not end in ':', or we
get this build error:

drivers/clk/pxa/clk-pxa.c: In function 'pxa2xx_core_turbo_switch':
drivers/clk/pxa/clk-pxa.c:152: error: expected string literal before ')' token

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/clk/pxa/clk-pxa.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/clk/pxa/clk-pxa.c b/drivers/clk/pxa/clk-pxa.c
index 74f64c3c4290..626ec5613bb1 100644
--- a/drivers/clk/pxa/clk-pxa.c
+++ b/drivers/clk/pxa/clk-pxa.c
@@ -148,8 +148,7 @@ void pxa2xx_core_turbo_switch(bool on)
 	"2:	b	1b\n"
 	"3:	nop\n"
 		: "=&r" (unused)
-		: "r" (clkcfg)
-		: );
+		: "r" (clkcfg));
 
 	local_irq_restore(flags);
 }
-- 
2.9.0

[PATCH 05/13] clk: pxa: fix gcc-4.4 build

[Arnd Bergmann]

With gcc-4.4 and earlier, the asm statement must not end in ':', or we
get this build error:

drivers/clk/pxa/clk-pxa.c: In function 'pxa2xx_core_turbo_switch':
drivers/clk/pxa/clk-pxa.c:152: error: expected string literal before ')' token

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/clk/pxa/clk-pxa.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/clk/pxa/clk-pxa.c b/drivers/clk/pxa/clk-pxa.c
index 74f64c3c4290..626ec5613bb1 100644
--- a/drivers/clk/pxa/clk-pxa.c
+++ b/drivers/clk/pxa/clk-pxa.c
@@ -148,8 +148,7 @@ void pxa2xx_core_turbo_switch(bool on)
 	"2:	b	1b\n"
 	"3:	nop\n"
 		: "=&r" (unused)
-		: "r" (clkcfg)
-		: );
+		: "r" (clkcfg));
 
 	local_irq_restore(flags);
 }
-- 
2.9.0

[PATCH 06/13] ARM: atomic: fix gcc-4.4 build

[Arnd Bergmann]

gcc-4.4 fails to build some files with this constraint, which was
added to help out with gcc-4.6 and higher:

fs/btrfs/delayed-ref.c: In function 'add_delayed_tree_ref':
arch/arm/include/asm/atomic.h:280: error: 'asm' operand requires impossible reload

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/include/asm/atomic.h | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
index 66d0e215a773..65d5b843831a 100644
--- a/arch/arm/include/asm/atomic.h
+++ b/arch/arm/include/asm/atomic.h
@@ -280,7 +280,10 @@ static inline long long atomic64_read(const atomic64_t *v)
 	__asm__ __volatile__("@ atomic64_read\n"
 "	ldrd	%0, %H0, [%1]"
 	: "=&r" (result)
-	: "r" (&v->counter), "Qo" (v->counter)
+	: "r" (&v->counter)
+#if GCC_VERSION >= 40600
+	, "Qo" (v->counter)
+#endif
 	);
 
 	return result;
@@ -302,7 +305,10 @@ static inline long long atomic64_read(const atomic64_t *v)
 	__asm__ __volatile__("@ atomic64_read\n"
 "	ldrexd	%0, %H0, [%1]"
 	: "=&r" (result)
-	: "r" (&v->counter), "Qo" (v->counter)
+	: "r" (&v->counter)
+#if GCC_VERSION >= 40600
+	, "Qo" (v->counter)
+#endif
 	);
 
 	return result;
-- 
2.9.0

[PATCH 06/13] ARM: atomic: fix gcc-4.4 build

[Arnd Bergmann]

gcc-4.4 fails to build some files with this constraint, which was
added to help out with gcc-4.6 and higher:

fs/btrfs/delayed-ref.c: In function 'add_delayed_tree_ref':
arch/arm/include/asm/atomic.h:280: error: 'asm' operand requires impossible reload

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/include/asm/atomic.h | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
index 66d0e215a773..65d5b843831a 100644
--- a/arch/arm/include/asm/atomic.h
+++ b/arch/arm/include/asm/atomic.h
@@ -280,7 +280,10 @@ static inline long long atomic64_read(const atomic64_t *v)
 	__asm__ __volatile__("@ atomic64_read\n"
 "	ldrd	%0, %H0, [%1]"
 	: "=&r" (result)
-	: "r" (&v->counter), "Qo" (v->counter)
+	: "r" (&v->counter)
+#if GCC_VERSION >= 40600
+	, "Qo" (v->counter)
+#endif
 	);
 
 	return result;
@@ -302,7 +305,10 @@ static inline long long atomic64_read(const atomic64_t *v)
 	__asm__ __volatile__("@ atomic64_read\n"
 "	ldrexd	%0, %H0, [%1]"
 	: "=&r" (result)
-	: "r" (&v->counter), "Qo" (v->counter)
+	: "r" (&v->counter)
+#if GCC_VERSION >= 40600
+	, "Qo" (v->counter)
+#endif
 	);
 
 	return result;
-- 
2.9.0

[PATCH 07/13] watchdog: kempld: fix gcc-4.3 build

[Arnd Bergmann]

gcc-4.3 can't decide whether the constant value in
kempld_prescaler[PRESCALER_21] is built-time constant or
not, and gets confused by the logic in do_div():

drivers/watchdog/kempld_wdt.o: In function `kempld_wdt_set_stage_timeout':
kempld_wdt.c:(.text.kempld_wdt_set_stage_timeout+0x130): undefined reference to `__aeabi_uldivmod'

This adds a call to ACCESS_ONCE() to force it to not consider
it to be constant, and leaves the more efficient normal case
in place for modern compilers, using an #ifdef to annotate
why we do this hack.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/watchdog/kempld_wdt.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/kempld_wdt.c b/drivers/watchdog/kempld_wdt.c
index 8e302d0e346c..3efa295ac627 100644
--- a/drivers/watchdog/kempld_wdt.c
+++ b/drivers/watchdog/kempld_wdt.c
@@ -140,12 +140,19 @@ static int kempld_wdt_set_stage_timeout(struct kempld_wdt_data *wdt_data,
 					unsigned int timeout)
 {
 	struct kempld_device_data *pld = wdt_data->pld;
-	u32 prescaler = kempld_prescaler[PRESCALER_21];
+	u32 prescaler;
 	u64 stage_timeout64;
 	u32 stage_timeout;
 	u32 remainder;
 	u8 stage_cfg;
 
+#if GCC_VERSION < 40400
+	/* work around a bug compiling do_div() */
+	prescaler = READ_ONCE(kempld_prescaler[PRESCALER_21]);
+#else
+	prescaler = kempld_prescaler[PRESCALER_21];
+#endif
+
 	if (!stage)
 		return -EINVAL;
 
-- 
2.9.0

[PATCH 07/13] watchdog: kempld: fix gcc-4.3 build

[Arnd Bergmann]

gcc-4.3 can't decide whether the constant value in
kempld_prescaler[PRESCALER_21] is built-time constant or
not, and gets confused by the logic in do_div():

drivers/watchdog/kempld_wdt.o: In function `kempld_wdt_set_stage_timeout':
kempld_wdt.c:(.text.kempld_wdt_set_stage_timeout+0x130): undefined reference to `__aeabi_uldivmod'

This adds a call to ACCESS_ONCE() to force it to not consider
it to be constant, and leaves the more efficient normal case
in place for modern compilers, using an #ifdef to annotate
why we do this hack.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/watchdog/kempld_wdt.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/kempld_wdt.c b/drivers/watchdog/kempld_wdt.c
index 8e302d0e346c..3efa295ac627 100644
--- a/drivers/watchdog/kempld_wdt.c
+++ b/drivers/watchdog/kempld_wdt.c
@@ -140,12 +140,19 @@ static int kempld_wdt_set_stage_timeout(struct kempld_wdt_data *wdt_data,
 					unsigned int timeout)
 {
 	struct kempld_device_data *pld = wdt_data->pld;
-	u32 prescaler = kempld_prescaler[PRESCALER_21];
+	u32 prescaler;
 	u64 stage_timeout64;
 	u32 stage_timeout;
 	u32 remainder;
 	u8 stage_cfg;
 
+#if GCC_VERSION < 40400
+	/* work around a bug compiling do_div() */
+	prescaler = READ_ONCE(kempld_prescaler[PRESCALER_21]);
+#else
+	prescaler = kempld_prescaler[PRESCALER_21];
+#endif
+
 	if (!stage)
 		return -EINVAL;
 
-- 
2.9.0

[PATCH 08/13] arm/arm64: xen: avoid gcc-4.4 warning

[Arnd Bergmann]

Ancient gcc doesn't know about __builtin_unreachable(), causing
lots of instances of a harmless warning:

include/xen/arm/page.h: In function 'arbitrary_virt_to_machine':
include/xen/arm/page.h:85: warning: no return statement in function returning non-void

Adding a return statement doesn't change the behavior here, but
shuts up that warning.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 include/xen/arm/page.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/xen/arm/page.h b/include/xen/arm/page.h
index 415dbc6e43fd..2485013e3c6f 100644
--- a/include/xen/arm/page.h
+++ b/include/xen/arm/page.h
@@ -82,6 +82,7 @@ static inline unsigned long bfn_to_pfn(unsigned long bfn)
 static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
 {
 	BUG();
+	return XMADDR(0);
 }
 
 /* TODO: this shouldn't be here but it is because the frontend drivers
-- 
2.9.0

[PATCH 08/13] arm/arm64: xen: avoid gcc-4.4 warning

[Arnd Bergmann]

Ancient gcc doesn't know about __builtin_unreachable(), causing
lots of instances of a harmless warning:

include/xen/arm/page.h: In function 'arbitrary_virt_to_machine':
include/xen/arm/page.h:85: warning: no return statement in function returning non-void

Adding a return statement doesn't change the behavior here, but
shuts up that warning.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 include/xen/arm/page.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/xen/arm/page.h b/include/xen/arm/page.h
index 415dbc6e43fd..2485013e3c6f 100644
--- a/include/xen/arm/page.h
+++ b/include/xen/arm/page.h
@@ -82,6 +82,7 @@ static inline unsigned long bfn_to_pfn(unsigned long bfn)
 static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
 {
 	BUG();
+	return XMADDR(0);
 }
 
 /* TODO: this shouldn't be here but it is because the frontend drivers
-- 
2.9.0

[PATCH 09/13] ARM: mark cmpxchg and xchg __always_inline for gcc-4.3

[Arnd Bergmann]

With older compiler versions like gcc-4.3 and CONFIG_OPTIMIZE_INLINING,
I run into link errors:

kernel/task_work.o: In function `__cmpxchg':
task_work.c:(.text+0x8c): undefined reference to `__bad_cmpxchg'
kernel/kthread.o: In function `__xchg':
kthread.c:(.text+0x7bc): undefined reference to `__bad_xchg'

This marks the functions in question as __always_inline to force
inlining.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/include/asm/cmpxchg.h | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h
index 12215515ba02..218ba0ae90cd 100644
--- a/arch/arm/include/asm/cmpxchg.h
+++ b/arch/arm/include/asm/cmpxchg.h
@@ -24,7 +24,8 @@
 #define swp_is_buggy
 #endif
 
-static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
+static __always_inline unsigned long
+__xchg(unsigned long x, volatile void *ptr, int size)
 {
 	extern void __bad_xchg(volatile void *, int);
 	unsigned long ret;
@@ -152,8 +153,8 @@ extern void __bad_cmpxchg(volatile void *ptr, int size);
  * cmpxchg only support 32-bits operands on ARMv6.
  */
 
-static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
-				      unsigned long new, int size)
+static __always_inline unsigned long
+__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new, int size)
 {
 	unsigned long oldval, res;
 
@@ -213,9 +214,8 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
 				      sizeof(*(ptr)));			\
 })
 
-static inline unsigned long __cmpxchg_local(volatile void *ptr,
-					    unsigned long old,
-					    unsigned long new, int size)
+static __always_inline unsigned long
+__cmpxchg_local(volatile void *ptr, unsigned long old, unsigned long new, int size)
 {
 	unsigned long ret;
 
-- 
2.9.0

[PATCH 09/13] ARM: mark cmpxchg and xchg __always_inline for gcc-4.3

[Arnd Bergmann]

With older compiler versions like gcc-4.3 and CONFIG_OPTIMIZE_INLINING,
I run into link errors:

kernel/task_work.o: In function `__cmpxchg':
task_work.c:(.text+0x8c): undefined reference to `__bad_cmpxchg'
kernel/kthread.o: In function `__xchg':
kthread.c:(.text+0x7bc): undefined reference to `__bad_xchg'

This marks the functions in question as __always_inline to force
inlining.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/include/asm/cmpxchg.h | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h
index 12215515ba02..218ba0ae90cd 100644
--- a/arch/arm/include/asm/cmpxchg.h
+++ b/arch/arm/include/asm/cmpxchg.h
@@ -24,7 +24,8 @@
 #define swp_is_buggy
 #endif
 
-static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
+static __always_inline unsigned long
+__xchg(unsigned long x, volatile void *ptr, int size)
 {
 	extern void __bad_xchg(volatile void *, int);
 	unsigned long ret;
@@ -152,8 +153,8 @@ extern void __bad_cmpxchg(volatile void *ptr, int size);
  * cmpxchg only support 32-bits operands on ARMv6.
  */
 
-static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
-				      unsigned long new, int size)
+static __always_inline unsigned long
+__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new, int size)
 {
 	unsigned long oldval, res;
 
@@ -213,9 +214,8 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
 				      sizeof(*(ptr)));			\
 })
 
-static inline unsigned long __cmpxchg_local(volatile void *ptr,
-					    unsigned long old,
-					    unsigned long new, int size)
+static __always_inline unsigned long
+__cmpxchg_local(volatile void *ptr, unsigned long old, unsigned long new, int size)
 {
 	unsigned long ret;
 
-- 
2.9.0

[PATCH 10/13] asm-generic: mark cmpxchg as __always_inline for gcc-4.3

[Arnd Bergmann]

With CONFIG_OPTIMIZE_INLINING and older compilers, we can get
a link error such as

kernel/task_work.o: In function `__cmpxchg_local_generic':
task_work.c:(.text+0x14c): undefined reference to `wrong_size_cmpxchg'
kernel/locking/rtmutex.o: In function `__cmpxchg_local_generic':
rtmutex.c:(.text+0x5ec): undefined reference to `wrong_size_cmpxchg'
kernel/trace/ring_buffer.o: In function `__cmpxchg_local_generic':

Marking the functions in question as __always_inline avoids that
possibility.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 include/asm-generic/cmpxchg-local.h | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/asm-generic/cmpxchg-local.h b/include/asm-generic/cmpxchg-local.h
index 70bef78912b7..e82d7032b1b8 100644
--- a/include/asm-generic/cmpxchg-local.h
+++ b/include/asm-generic/cmpxchg-local.h
@@ -11,7 +11,8 @@ extern unsigned long wrong_size_cmpxchg(volatile void *ptr)
  * Generic version of __cmpxchg_local (disables interrupts). Takes an unsigned
  * long parameter, supporting various types of architectures.
  */
-static inline unsigned long __cmpxchg_local_generic(volatile void *ptr,
+static __always_inline unsigned long
+__cmpxchg_local_generic(volatile void *ptr,
 		unsigned long old, unsigned long new, int size)
 {
 	unsigned long flags, prev;
@@ -50,8 +51,8 @@ static inline unsigned long __cmpxchg_local_generic(volatile void *ptr,
 /*
  * Generic version of __cmpxchg64_local. Takes an u64 parameter.
  */
-static inline u64 __cmpxchg64_local_generic(volatile void *ptr,
-		u64 old, u64 new)
+static __always_inline u64
+__cmpxchg64_local_generic(volatile void *ptr, u64 old, u64 new)
 {
 	u64 prev;
 	unsigned long flags;
-- 
2.9.0

[PATCH 10/13] asm-generic: mark cmpxchg as __always_inline for gcc-4.3

[Arnd Bergmann]

With CONFIG_OPTIMIZE_INLINING and older compilers, we can get
a link error such as

kernel/task_work.o: In function `__cmpxchg_local_generic':
task_work.c:(.text+0x14c): undefined reference to `wrong_size_cmpxchg'
kernel/locking/rtmutex.o: In function `__cmpxchg_local_generic':
rtmutex.c:(.text+0x5ec): undefined reference to `wrong_size_cmpxchg'
kernel/trace/ring_buffer.o: In function `__cmpxchg_local_generic':

Marking the functions in question as __always_inline avoids that
possibility.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 include/asm-generic/cmpxchg-local.h | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/asm-generic/cmpxchg-local.h b/include/asm-generic/cmpxchg-local.h
index 70bef78912b7..e82d7032b1b8 100644
--- a/include/asm-generic/cmpxchg-local.h
+++ b/include/asm-generic/cmpxchg-local.h
@@ -11,7 +11,8 @@ extern unsigned long wrong_size_cmpxchg(volatile void *ptr)
  * Generic version of __cmpxchg_local (disables interrupts). Takes an unsigned
  * long parameter, supporting various types of architectures.
  */
-static inline unsigned long __cmpxchg_local_generic(volatile void *ptr,
+static __always_inline unsigned long
+__cmpxchg_local_generic(volatile void *ptr,
 		unsigned long old, unsigned long new, int size)
 {
 	unsigned long flags, prev;
@@ -50,8 +51,8 @@ static inline unsigned long __cmpxchg_local_generic(volatile void *ptr,
 /*
  * Generic version of __cmpxchg64_local. Takes an u64 parameter.
  */
-static inline u64 __cmpxchg64_local_generic(volatile void *ptr,
-		u64 old, u64 new)
+static __always_inline u64
+__cmpxchg64_local_generic(volatile void *ptr, u64 old, u64 new)
 {
 	u64 prev;
 	unsigned long flags;
-- 
2.9.0

[PATCH 11/13] fs: fix unsigned enum warning with gcc-4.2

[Arnd Bergmann]

With arm-linux-gcc-4.2, almost every file we build in the kernel ends
up with this warning:

include/linux/fs.h:2648: warning: comparison of unsigned expression < 0 is always false

Later versions don't have this problem, but it's easy enough to
work around.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 include/linux/fs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 398cf20a706d..782c2a292fd7 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2645,7 +2645,7 @@ static const char * const kernel_read_file_str[] = {
 
 static inline const char *kernel_read_file_id_str(enum kernel_read_file_id id)
 {
-	if (id < 0 || id >= READING_MAX_ID)
+	if ((unsigned)id >= READING_MAX_ID)
 		return kernel_read_file_str[READING_UNKNOWN];
 
 	return kernel_read_file_str[id];
-- 
2.9.0

[PATCH 11/13] fs: fix unsigned enum warning with gcc-4.2

[Arnd Bergmann]

With arm-linux-gcc-4.2, almost every file we build in the kernel ends
up with this warning:

include/linux/fs.h:2648: warning: comparison of unsigned expression < 0 is always false

Later versions don't have this problem, but it's easy enough to
work around.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 include/linux/fs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 398cf20a706d..782c2a292fd7 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2645,7 +2645,7 @@ static const char * const kernel_read_file_str[] = {
 
 static inline const char *kernel_read_file_id_str(enum kernel_read_file_id id)
 {
-	if (id < 0 || id >= READING_MAX_ID)
+	if ((unsigned)id >= READING_MAX_ID)
 		return kernel_read_file_str[READING_UNKNOWN];
 
 	return kernel_read_file_str[id];
-- 
2.9.0

Re: [PATCH 11/13] fs: fix unsigned enum warning with gcc-4.2

[Brendan Gregg]

On Fri, Dec 16, 2016 at 2:56 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> With arm-linux-gcc-4.2, almost every file we build in the kernel ends
> up with this warning:
>
> include/linux/fs.h:2648: warning: comparison of unsigned expression < 0 is always false
>

Thanks, I'd like to see this fixed as a similar warning gets printed
whenever running many of the bcc/BPF tools, which gets annoying and is
user-visible. eg:

# /usr/share/bcc/tools/xfsslower 1
In file included from /virtual/main.c:3:
/lib/modules/4.8.6-300.fc25.x86_64/build/include/linux/fs.h:2677:9:
warning: comparison of unsigned enum expression < 0 is always false
[-Wtautological-compare]
        if (id < 0 || id >= READING_MAX_ID)
            ~~ ^ ~
1 warning generated.
Tracing XFS operations slower than 1 ms
TIME     COMM           PID    T BYTES   OFF_KB   LAT(ms) FILENAME
14:44:27 cksum          4414   R 65536   0           1.02 chcon
14:44:27 cksum          4414   R 65536   0           1.20 cpio
14:44:27 cksum          4414   R 65536   0           1.01 diff
14:44:27 cksum          4414   R 65536   0           1.15 dir
[...]

This patch fixes the warning.

Brendan

>
> Later versions don't have this problem, but it's easy enough to
> work around.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  include/linux/fs.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 398cf20a706d..782c2a292fd7 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2645,7 +2645,7 @@ static const char * const kernel_read_file_str[] = {
>
>  static inline const char *kernel_read_file_id_str(enum kernel_read_file_id id)
>  {
> -       if (id < 0 || id >= READING_MAX_ID)
> +       if ((unsigned)id >= READING_MAX_ID)
>                 return kernel_read_file_str[READING_UNKNOWN];
>
>         return kernel_read_file_str[id];
> --
> 2.9.0
>

Re: [PATCH 11/13] fs: fix unsigned enum warning with gcc-4.2

[Brendan Gregg]

On Tue, Jan 3, 2017 at 2:47 PM, Brendan Gregg <brendan.d.gregg@gmail.com> wrote:
>
> On Fri, Dec 16, 2016 at 2:56 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > With arm-linux-gcc-4.2, almost every file we build in the kernel ends
> > up with this warning:
> >
> > include/linux/fs.h:2648: warning: comparison of unsigned expression < 0 is always false
> >
>
> Thanks, I'd like to see this fixed as a similar warning gets printed
> whenever running many of the bcc/BPF tools, which gets annoying and is
> user-visible. eg:
>
> # /usr/share/bcc/tools/xfsslower 1
> In file included from /virtual/main.c:3:
> /lib/modules/4.8.6-300.fc25.x86_64/build/include/linux/fs.h:2677:9:
> warning: comparison of unsigned enum expression < 0 is always false
> [-Wtautological-compare]
>         if (id < 0 || id >= READING_MAX_ID)
>             ~~ ^ ~
> 1 warning generated.
> Tracing XFS operations slower than 1 ms
> TIME     COMM           PID    T BYTES   OFF_KB   LAT(ms) FILENAME
> 14:44:27 cksum          4414   R 65536   0           1.02 chcon
> 14:44:27 cksum          4414   R 65536   0           1.20 cpio
> 14:44:27 cksum          4414   R 65536   0           1.01 diff
> 14:44:27 cksum          4414   R 65536   0           1.15 dir
> [...]
>
> This patch fixes the warning.
>

What's the status of this patch? I still get these warnings on latest. Thanks,

Brendan

[PATCH 12/13] KVM: arm: avoid binary number literals for gcc-4.2

[Arnd Bergmann]

Old gcc versions prior to 4.3 don't understand the 0b... syntax for
numbers, and this seems to be the only instance in the kernel, so better
use hexadecimal instead.

arch/arm/include/asm/kvm_mmu.h:127:38: error: invalid suffix "b101" on integer constant

Fixes: 159793001d7d ("ARM: KVM: force cache clean on page fault when caches are off")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/include/asm/kvm_mmu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 74a44727f8e1..61121300174f 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -124,7 +124,7 @@ struct kvm;
 
 static inline bool vcpu_has_cache_enabled(struct kvm_vcpu *vcpu)
 {
-	return (vcpu_cp15(vcpu, c1_SCTLR) & 0b101) == 0b101;
+	return (vcpu_cp15(vcpu, c1_SCTLR) & 0x5) == 0x5;
 }
 
 static inline void __coherent_cache_guest_page(struct kvm_vcpu *vcpu,
-- 
2.9.0

[PATCH 12/13] KVM: arm: avoid binary number literals for gcc-4.2

[Arnd Bergmann]

Old gcc versions prior to 4.3 don't understand the 0b... syntax for
numbers, and this seems to be the only instance in the kernel, so better
use hexadecimal instead.

arch/arm/include/asm/kvm_mmu.h:127:38: error: invalid suffix "b101" on integer constant

Fixes: 159793001d7d ("ARM: KVM: force cache clean on page fault when caches are off")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/include/asm/kvm_mmu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 74a44727f8e1..61121300174f 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -124,7 +124,7 @@ struct kvm;
 
 static inline bool vcpu_has_cache_enabled(struct kvm_vcpu *vcpu)
 {
-	return (vcpu_cp15(vcpu, c1_SCTLR) & 0b101) == 0b101;
+	return (vcpu_cp15(vcpu, c1_SCTLR) & 0x5) == 0x5;
 }
 
 static inline void __coherent_cache_guest_page(struct kvm_vcpu *vcpu,
-- 
2.9.0

Re: [PATCH 12/13] KVM: arm: avoid binary number literals for gcc-4.2

[Christoffer Dall]

On Fri, Dec 16, 2016 at 11:56:33AM +0100, Arnd Bergmann wrote:
> Old gcc versions prior to 4.3 don't understand the 0b... syntax for
> numbers, and this seems to be the only instance in the kernel, so better
> use hexadecimal instead.
> 
> arch/arm/include/asm/kvm_mmu.h:127:38: error: invalid suffix "b101" on integer constant
> 
> Fixes: 159793001d7d ("ARM: KVM: force cache clean on page fault when caches are off")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Same as before:
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>

Re: [PATCH 12/13] KVM: arm: avoid binary number literals for gcc-4.2

[Christoffer Dall]

On Fri, Dec 16, 2016 at 11:56:33AM +0100, Arnd Bergmann wrote:
> Old gcc versions prior to 4.3 don't understand the 0b... syntax for
> numbers, and this seems to be the only instance in the kernel, so better
> use hexadecimal instead.
> 
> arch/arm/include/asm/kvm_mmu.h:127:38: error: invalid suffix "b101" on integer constant
> 
> Fixes: 159793001d7d ("ARM: KVM: force cache clean on page fault when caches are off")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Same as before:
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>

[PATCH 13/13] ARM: avoid 'Q' asm constraint for gcc-4.1 and earlier

[Arnd Bergmann]

Building with ancient gcc versions results in a stream of build errors
like:

arch/arm/include/asm/io.h:100: error: impossible constraint in 'asm'
arch/arm/include/asm/io.h:118: error: impossible constraint in 'asm'

This reverts to an older version of __raw_readl, __raw_writel
and __my_cpu_offset, which seem to be the only functions affected
by this.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/include/asm/io.h     | 8 ++++++++
 arch/arm/include/asm/percpu.h | 5 ++++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 6f89a4d9fc85..d0f89c4cb8e2 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -97,8 +97,12 @@ static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
 #define __raw_writel __raw_writel
 static inline void __raw_writel(u32 val, volatile void __iomem *addr)
 {
+#if GCC_VERSION < 40200
+	*(volatile u32 __force *)addr = val;
+#else
 	asm volatile("str %1, %0"
 		     : : "Qo" (*(volatile u32 __force *)addr), "r" (val));
+#endif
 }
 
 #define __raw_readb __raw_readb
@@ -115,9 +119,13 @@ static inline u8 __raw_readb(const volatile void __iomem *addr)
 static inline u32 __raw_readl(const volatile void __iomem *addr)
 {
 	u32 val;
+#if GCC_VERSION < 40200
+	val = *(volatile u32 __force *)addr;
+#else
 	asm volatile("ldr %0, %1"
 		     : "=r" (val)
 		     : "Qo" (*(volatile u32 __force *)addr));
+#endif
 	return val;
 }
 
diff --git a/arch/arm/include/asm/percpu.h b/arch/arm/include/asm/percpu.h
index a89b4076cde4..dee4c89b4458 100644
--- a/arch/arm/include/asm/percpu.h
+++ b/arch/arm/include/asm/percpu.h
@@ -36,9 +36,12 @@ static inline unsigned long __my_cpu_offset(void)
 	 * We want to allow caching the value, so avoid using volatile and
 	 * instead use a fake stack read to hazard against barrier().
 	 */
+#if GCC_VERSION < 40200
+	asm("mrc p15, 0, %0, c13, c0, 4" : "=r" (off) : : "memory");
+#else
 	asm("mrc p15, 0, %0, c13, c0, 4" : "=r" (off)
 		: "Q" (*(const unsigned long *)current_stack_pointer));
-
+#endif
 	return off;
 }
 #define __my_cpu_offset __my_cpu_offset()
-- 
2.9.0

[PATCH 13/13] ARM: avoid 'Q' asm constraint for gcc-4.1 and earlier

[Arnd Bergmann]

Building with ancient gcc versions results in a stream of build errors
like:

arch/arm/include/asm/io.h:100: error: impossible constraint in 'asm'
arch/arm/include/asm/io.h:118: error: impossible constraint in 'asm'

This reverts to an older version of __raw_readl, __raw_writel
and __my_cpu_offset, which seem to be the only functions affected
by this.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/include/asm/io.h     | 8 ++++++++
 arch/arm/include/asm/percpu.h | 5 ++++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 6f89a4d9fc85..d0f89c4cb8e2 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -97,8 +97,12 @@ static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
 #define __raw_writel __raw_writel
 static inline void __raw_writel(u32 val, volatile void __iomem *addr)
 {
+#if GCC_VERSION < 40200
+	*(volatile u32 __force *)addr = val;
+#else
 	asm volatile("str %1, %0"
 		     : : "Qo" (*(volatile u32 __force *)addr), "r" (val));
+#endif
 }
 
 #define __raw_readb __raw_readb
@@ -115,9 +119,13 @@ static inline u8 __raw_readb(const volatile void __iomem *addr)
 static inline u32 __raw_readl(const volatile void __iomem *addr)
 {
 	u32 val;
+#if GCC_VERSION < 40200
+	val = *(volatile u32 __force *)addr;
+#else
 	asm volatile("ldr %0, %1"
 		     : "=r" (val)
 		     : "Qo" (*(volatile u32 __force *)addr));
+#endif
 	return val;
 }
 
diff --git a/arch/arm/include/asm/percpu.h b/arch/arm/include/asm/percpu.h
index a89b4076cde4..dee4c89b4458 100644
--- a/arch/arm/include/asm/percpu.h
+++ b/arch/arm/include/asm/percpu.h
@@ -36,9 +36,12 @@ static inline unsigned long __my_cpu_offset(void)
 	 * We want to allow caching the value, so avoid using volatile and
 	 * instead use a fake stack read to hazard against barrier().
 	 */
+#if GCC_VERSION < 40200
+	asm("mrc p15, 0, %0, c13, c0, 4" : "=r" (off) : : "memory");
+#else
 	asm("mrc p15, 0, %0, c13, c0, 4" : "=r" (off)
 		: "Q" (*(const unsigned long *)current_stack_pointer));
-
+#endif
 	return off;
 }
 #define __my_cpu_offset __my_cpu_offset()
-- 
2.9.0

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

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

Re: [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

Re: [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

Re: [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

Re: [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

Re: [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

Re: [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

Re: [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

Re: [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

Re: [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

Re: [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

Re: [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

Re: [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

Re: [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@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

Re: [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@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

Re: [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

Re: [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

Re: [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@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

Re: [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@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

Re: [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

Re: [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

Re: [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

Re: [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@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

Re: [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@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

Re: [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

Re: [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

Re: [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

Re: [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

Re: [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@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

Re: [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@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

Re: [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

Re: [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

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

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

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

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

[Arnd Bergmann]

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

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

[Arnd Bergmann]

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

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

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

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

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

[Sebastian Andrzej Siewior]

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

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

[Arnd Bergmann]

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

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

[Arnd Bergmann]

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

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

[Sebastian Andrzej Siewior]

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

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

[Sebastian Andrzej Siewior]

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

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

[Russell King - ARM Linux]

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.

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

[Russell King - ARM Linux]

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.

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

[Heiko Carstens]

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

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

[Heiko Carstens]

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