Build failures with gcc 4.5 and older

Build failures with gcc 4.5 and older

[Guenter Roeck]

Hi,

Since commit c1a2f7f0c0645 ("mm: Allocate the mm_cpumask
(mm->cpu_bitmap[]) dynamically based on nr_cpu_ids"), building
the Linux kernel with gcc version 4.5 and older fails as follows.

In file included from ./include/linux/mm.h:17:0,
                 from ./include/linux/pid_namespace.h:7,
		 from ./include/linux/ptrace.h:10,
		 from arch/openrisc/kernel/asm-offsets.c:32:
./include/linux/mm_types.h:497:16: error: flexible array member in otherwise empty struct

This is just an example with gcc 4.5.1 for or32. I have seen the problem
with gcc 4.4 (for unicore32) as well.

Does that mean that gcc 4.5 and older are now officially no longer
supported for compiling the kernel ?

If so, would it make sense to update include/linux/compiler-gcc.h
accordingly ?

Thanks,
Guenter

Re: Build failures with gcc 4.5 and older

[Linus Torvalds]

On Tue, Aug 14, 2018 at 10:09 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> Does that mean that gcc 4.5 and older are now officially no longer
> supported for compiling the kernel ?

I guess we might as well make this the excuse for making that official.

Maybe it's trivially fixable, but I don't even want to look at it,
since we've talked about updating the minimum gcc version so long.

> If so, would it make sense to update include/linux/compiler-gcc.h
> accordingly ?

Unless somebody cares, and comes with a trivial fix to make old
compilers happy, let's just do that.

We had some other reasons to just say gcc-4.6 is the minimum version anyway.

            Linus

Re: Build failures with gcc 4.5 and older

[Guenter Roeck]

On Tue, Aug 14, 2018 at 10:20:32AM -0700, Linus Torvalds wrote:
> On Tue, Aug 14, 2018 at 10:09 AM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Does that mean that gcc 4.5 and older are now officially no longer
> > supported for compiling the kernel ?
> 
> I guess we might as well make this the excuse for making that official.
> 
> Maybe it's trivially fixable, but I don't even want to look at it,
> since we've talked about updating the minimum gcc version so long.
> 
> > If so, would it make sense to update include/linux/compiler-gcc.h
> > accordingly ?
> 
> Unless somebody cares, and comes with a trivial fix to make old
> compilers happy, let's just do that.
> 

Only implication is that it is the death warrant for unicore32,
since the only compiler available for it is gcc 4.4.2.

Another question is if there are still companies out there who only
permit gcc 4.4 and older due to its switch to GPL3.

Not that I care about any of those. Building the kernel with those old
compilers without hitting some compiler bug is getting more and more
difficult.

Guenter

Re: Build failures with gcc 4.5 and older

[Joe Perches]

On Tue, 2018-08-14 at 10:09 -0700, Guenter Roeck wrote:
> Hi,
> 
> Since commit c1a2f7f0c0645 ("mm: Allocate the mm_cpumask
> (mm->cpu_bitmap[]) dynamically based on nr_cpu_ids"), building
> the Linux kernel with gcc version 4.5 and older fails as follows.
> 
> In file included from ./include/linux/mm.h:17:0,
>                  from ./include/linux/pid_namespace.h:7,
> 		 from ./include/linux/ptrace.h:10,
> 		 from arch/openrisc/kernel/asm-offsets.c:32:
> ./include/linux/mm_types.h:497:16: error: flexible array member in otherwise empty struct
> 
> This is just an example with gcc 4.5.1 for or32. I have seen the problem
> with gcc 4.4 (for unicore32) as well.
> 
> Does that mean that gcc 4.5 and older are now officially no longer
> supported for compiling the kernel ?
> 
> If so, would it make sense to update include/linux/compiler-gcc.h
> accordingly ?

And Documentation/process/changes.rst which shows a
minimum version required of gcc as 3.2, etc...

With cleaning up now unnecessary version tests in
compiler-gcc.h, something like:
---
 Documentation/process/changes.rst |  2 +-
 include/linux/compiler-gcc.h      | 86 ++++++++-------------------------------
 2 files changed, 19 insertions(+), 69 deletions(-)

diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
index 7a92a06f90de..61f918b10a0c 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -29,7 +29,7 @@ you probably needn't concern yourself with isdn4k-utils.
 ====================== ===============  ========================================
         Program        Minimal version       Command to check the version
 ====================== ===============  ========================================
-GNU C                  3.2              gcc --version
+GNU C                  4.6              gcc --version
 GNU make               3.81             make --version
 binutils               2.20             ld -v
 flex                   2.5.35           flex --version
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 573f5a7d42d4..020e4b9eee5c 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -10,6 +10,10 @@
 		     + __GNUC_MINOR__ * 100	\
 		     + __GNUC_PATCHLEVEL__)
 
+#if GCC_VERSION < 40600
+# error Sorry, your compiler is too old - please upgrade it.
+#endif
+
 /* Optimization barrier */
 
 /* The "volatile" is due to gcc bugs */
@@ -58,6 +62,12 @@
 #define OPTIMIZER_HIDE_VAR(var)						\
 	__asm__ ("" : "=r" (var) : "0" (var))
 
+/*
+ * A trick to suppress uninitialized variable warning without generating any
+ * code
+ */
+#define uninitialized_var(x) x = x
+
 #ifdef __CHECKER__
 #define __must_be_array(a)	0
 #else
@@ -91,7 +101,7 @@
  * A lot of inline functions can cause havoc with function tracing.
  */
 #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) ||		\
-    !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
+    !defined(CONFIG_OPTIMIZE_INLINING)
 #define inline \
 	inline __attribute__((always_inline, unused)) notrace __gnu_inline
 #else
@@ -148,47 +158,13 @@
 #define __always_unused		__attribute__((unused))
 #define __mode(x)               __attribute__((mode(x)))
 
-/* gcc version specific checks */
-
-#if GCC_VERSION < 30200
-# error Sorry, your compiler is too old - please upgrade it.
-#endif
-
-#if GCC_VERSION < 30300
-# define __used			__attribute__((__unused__))
-#else
-# define __used			__attribute__((__used__))
-#endif
-
-#ifdef CONFIG_GCOV_KERNEL
-# if GCC_VERSION < 30400
-#   error "GCOV profiling support for gcc versions below 3.4 not included"
-# endif /* __GNUC_MINOR__ */
-#endif /* CONFIG_GCOV_KERNEL */
-
-#if GCC_VERSION >= 30400
 #define __must_check		__attribute__((warn_unused_result))
 #define __malloc		__attribute__((__malloc__))
-#endif
-
-#if GCC_VERSION >= 40000
-
-/* GCC 4.1.[01] miscompiles __weak */
-#ifdef __KERNEL__
-# if GCC_VERSION >= 40100 &&  GCC_VERSION <= 40101
-#  error Your version of gcc miscompiles the __weak directive
-# endif
-#endif
 
 #define __used			__attribute__((__used__))
 #define __compiler_offsetof(a, b)					\
 	__builtin_offsetof(a, b)
 
-#if GCC_VERSION >= 40100
-# define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
-#endif
-
-#if GCC_VERSION >= 40300
 /* Mark functions as cold. gcc will assume any path leading to a call
  * to them will be unlikely.  This means a lot of manual unlikely()s
  * are unnecessary now for any paths leading to the usual suspects
@@ -207,24 +183,19 @@
 
 #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
 
-#ifndef __CHECKER__
-# define __compiletime_warning(message) __attribute__((warning(message)))
-# define __compiletime_error(message) __attribute__((error(message)))
-#endif /* __CHECKER__ */
-#endif /* GCC_VERSION >= 40300 */
-
-#if GCC_VERSION >= 40400
 #define __optimize(level)	__attribute__((__optimize__(level)))
 #define __nostackprotector	__optimize("no-stack-protector")
-#endif /* GCC_VERSION >= 40400 */
 
-#if GCC_VERSION >= 40500
+#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
 
 #ifndef __CHECKER__
+#define __compiletime_warning(message) __attribute__((warning(message)))
+#define __compiletime_error(message) __attribute__((error(message)))
+
 #ifdef LATENT_ENTROPY_PLUGIN
 #define __latent_entropy __attribute__((latent_entropy))
 #endif
-#endif
+#endif /* __CHECKER__ */
 
 /*
  * calling noreturn functions, __builtin_unreachable() and __builtin_trap()
@@ -262,10 +233,6 @@
 #define randomized_struct_fields_end	} __randomize_layout;
 #endif
 
-#endif /* GCC_VERSION >= 40500 */
-
-#if GCC_VERSION >= 40600
-
 /*
  * When used with Link Time Optimization, gcc can optimize away C functions or
  * variables which are referenced only from assembly code.  __visible tells the
@@ -274,8 +241,7 @@
  */
 #define __visible	__attribute__((externally_visible))
 
-#endif /* GCC_VERSION >= 40600 */
-
+/* gcc version specific checks */
 
 #if GCC_VERSION >= 40900 && !defined(__CHECKER__)
 /*
@@ -309,10 +275,8 @@
  * folding in __builtin_bswap*() (yet), so don't set these for it.
  */
 #if defined(CONFIG_ARCH_USE_BUILTIN_BSWAP) && !defined(__CHECKER__)
-#if GCC_VERSION >= 40400
 #define __HAVE_BUILTIN_BSWAP32__
 #define __HAVE_BUILTIN_BSWAP64__
-#endif
 #if GCC_VERSION >= 40800
 #define __HAVE_BUILTIN_BSWAP16__
 #endif
@@ -341,10 +305,9 @@
  * https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
  */
 #define __designated_init __attribute__((designated_init))
+#define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
 #endif
 
-#endif	/* gcc version >= 40000 specific checks */
-
 #if !defined(__noclone)
 #define __noclone	/* not needed */
 #endif
@@ -353,16 +316,6 @@
 #define __no_sanitize_address
 #endif
 
-/*
- * A trick to suppress uninitialized variable warning without generating any
- * code
- */
-#define uninitialized_var(x) x = x
-
-#if GCC_VERSION >= 50100
-#define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
-#endif
-
 /*
  * Turn individual warnings and errors on and off locally, depending
  * on version.
@@ -375,12 +328,9 @@
 #define __diag_GCC_warn		warning
 #define __diag_GCC_error	error
 
-/* Compilers before gcc-4.6 do not understand "#pragma GCC diagnostic push" */
-#if GCC_VERSION >= 40600
 #define __diag_str1(s)		#s
 #define __diag_str(s)		__diag_str1(s)
 #define __diag(s)		_Pragma(__diag_str(GCC diagnostic s))
-#endif
 
 #if GCC_VERSION >= 80000
 #define __diag_GCC_8(s)		__diag(s)

Re: Build failures with gcc 4.5 and older

[Tony Luck]

On Tue, Aug 14, 2018 at 11:02 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Tue, Aug 14, 2018 at 10:20:32AM -0700, Linus Torvalds wrote:
> > On Tue, Aug 14, 2018 at 10:09 AM Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > Does that mean that gcc 4.5 and older are now officially no longer
> > > supported for compiling the kernel ?
> >
> > I guess we might as well make this the excuse for making that official.
> >
> > Maybe it's trivially fixable, but I don't even want to look at it,
> > since we've talked about updating the minimum gcc version so long.
> >
> > > If so, would it make sense to update include/linux/compiler-gcc.h
> > > accordingly ?
> >
> > Unless somebody cares, and comes with a trivial fix to make old
> > compilers happy, let's just do that.
> >
>
> Only implication is that it is the death warrant for unicore32,
> since the only compiler available for it is gcc 4.4.2.

My ia64 test box only has 4.3.4.  I seem to remember some pain points
with newer versions of gcc on ia64. I need to poke around and find one
new enough to get past this problem, but that still works for kernel building.

-Tony

Re: Build failures with gcc 4.5 and older

[Andrew Morton]

On Tue, 14 Aug 2018 10:09:04 -0700 Guenter Roeck <linux@roeck-us.net> wrote:

> Since commit c1a2f7f0c0645 ("mm: Allocate the mm_cpumask
> (mm->cpu_bitmap[]) dynamically based on nr_cpu_ids"), building
> the Linux kernel with gcc version 4.5 and older fails as follows.
> 
> In file included from ./include/linux/mm.h:17:0,
>                  from ./include/linux/pid_namespace.h:7,
> 		 from ./include/linux/ptrace.h:10,
> 		 from arch/openrisc/kernel/asm-offsets.c:32:
> ./include/linux/mm_types.h:497:16: error: flexible array member in otherwise empty struct

Confused.  Why does it think that the mm_struct is "otherwise empty"?

This shuts it up:

--- a/include/linux/mm_types.h~a
+++ a/include/linux/mm_types.h
@@ -490,6 +490,7 @@ struct mm_struct {
 #endif
 	} __randomize_layout;
 
+	int wibble;
 	/*
 	 * The mm_cpumask needs to be at the end of mm_struct, because it
 	 * is dynamically sized based on nr_cpu_ids.


So we could add something like that, along with the appropriate #if
GCC_VERSION and a comment.  A simple enough change, to keep those old
gcc versions limping along for a bit longer?

Re: Build failures with gcc 4.5 and older

[Guenter Roeck]

On Tue, Aug 14, 2018 at 02:36:55PM -0700, Andrew Morton wrote:
> On Tue, 14 Aug 2018 10:09:04 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
> 
> > Since commit c1a2f7f0c0645 ("mm: Allocate the mm_cpumask
> > (mm->cpu_bitmap[]) dynamically based on nr_cpu_ids"), building
> > the Linux kernel with gcc version 4.5 and older fails as follows.
> > 
> > In file included from ./include/linux/mm.h:17:0,
> >                  from ./include/linux/pid_namespace.h:7,
> > 		 from ./include/linux/ptrace.h:10,
> > 		 from arch/openrisc/kernel/asm-offsets.c:32:
> > ./include/linux/mm_types.h:497:16: error: flexible array member in otherwise empty struct
 
> Confused.  Why does it think that the mm_struct is "otherwise empty"?
> 

The problem isn't really that the structure is otherwise empty.
Some digging reveals that the error message is wrong; gcc should
instead complain about having no _named_ structure element before
the flexible array member.

> This shuts it up:
> 
> --- a/include/linux/mm_types.h~a
> +++ a/include/linux/mm_types.h
> @@ -490,6 +490,7 @@ struct mm_struct {
>  #endif
>  	} __randomize_layout;
>  
> +	int wibble;
>  	/*
>  	 * The mm_cpumask needs to be at the end of mm_struct, because it
>  	 * is dynamically sized based on nr_cpu_ids.
> 

Unfortunately, that only triggers secondary errors.
Seen with both gcc 4.4 and 4.5.

mm/init-mm.c:29: error: unknown field ‘mm_rb’ specified in initializer
mm/init-mm.c:29: warning: missing braces around initializer
mm/init-mm.c:29: warning: (near initialization for ‘init_mm.<anonymous>’)
mm/init-mm.c:29: error: incompatible types when initializing type ‘struct
vm_area_struct *’ using type ‘struct rb_root’
mm/init-mm.c:30: error: unknown field ‘pgd’ specified in initializer

and many more similar errors.

Guenter

Re: Build failures with gcc 4.5 and older

[Andrew Morton]

On Tue, 14 Aug 2018 15:15:59 -0700 Guenter Roeck <linux@roeck-us.net> wrote:

> > Confused.  Why does it think that the mm_struct is "otherwise empty"?
> > 
> 
> The problem isn't really that the structure is otherwise empty.
> Some digging reveals that the error message is wrong; gcc should
> instead complain about having no _named_ structure element before
> the flexible array member.
> 
> > This shuts it up:
> > 
> > --- a/include/linux/mm_types.h~a
> > +++ a/include/linux/mm_types.h
> > @@ -490,6 +490,7 @@ struct mm_struct {
> >  #endif
> >  	} __randomize_layout;
> >  
> > +	int wibble;
> >  	/*
> >  	 * The mm_cpumask needs to be at the end of mm_struct, because it
> >  	 * is dynamically sized based on nr_cpu_ids.
> > 
> 
> Unfortunately, that only triggers secondary errors.
> Seen with both gcc 4.4 and 4.5.
> 
> mm/init-mm.c:29: error: unknown field ‘mm_rb’ specified in initializer
> mm/init-mm.c:29: warning: missing braces around initializer
> mm/init-mm.c:29: warning: (near initialization for ‘init_mm.<anonymous>’)
> mm/init-mm.c:29: error: incompatible types when initializing type ‘struct
> vm_area_struct *’ using type ‘struct rb_root’
> mm/init-mm.c:30: error: unknown field ‘pgd’ specified in initializer
> 
> and many more similar errors.

This works, I think.

The m68k build still fails because 0cc3cd21657 ("cpu/hotplug: Boot HT
siblings at least once") was evidently never tested on CONFIG_SMP=n. 
How could that come about - the patch is six weeks old??

kernel/cpu.c: In function 'boot_cpu_hotplug_init':
kernel/cpu.c:2275:2: error: 'struct cpuhp_cpu_state' has no member named 'booted_once'


--- a/include/linux/mm_types.h~a
+++ a/include/linux/mm_types.h
@@ -490,6 +490,8 @@ struct mm_struct {
 #endif
 	} __randomize_layout;
 
+	int wibble;
+
 	/*
 	 * The mm_cpumask needs to be at the end of mm_struct, because it
 	 * is dynamically sized based on nr_cpu_ids.
--- a/mm/init-mm.c~a
+++ a/mm/init-mm.c
@@ -26,15 +26,17 @@
  * and size this cpu_bitmask to NR_CPUS.
  */
 struct mm_struct init_mm = {
-	.mm_rb		= RB_ROOT,
-	.pgd		= swapper_pg_dir,
-	.mm_users	= ATOMIC_INIT(2),
-	.mm_count	= ATOMIC_INIT(1),
-	.mmap_sem	= __RWSEM_INITIALIZER(init_mm.mmap_sem),
-	.page_table_lock =  __SPIN_LOCK_UNLOCKED(init_mm.page_table_lock),
-	.arg_lock	=  __SPIN_LOCK_UNLOCKED(init_mm.arg_lock),
-	.mmlist		= LIST_HEAD_INIT(init_mm.mmlist),
-	.user_ns	= &init_user_ns,
+	{
+		.mm_rb		= RB_ROOT,
+		.pgd		= swapper_pg_dir,
+		.mm_users	= ATOMIC_INIT(2),
+		.mm_count	= ATOMIC_INIT(1),
+		.mmap_sem	= __RWSEM_INITIALIZER(init_mm.mmap_sem),
+		.page_table_lock = __SPIN_LOCK_UNLOCKED(init_mm.page_table_lock),
+		.arg_lock	= __SPIN_LOCK_UNLOCKED(init_mm.arg_lock),
+		.mmlist		= LIST_HEAD_INIT(init_mm.mmlist),
+		.user_ns	= &init_user_ns,
+	},
 	.cpu_bitmap	= { [BITS_TO_LONGS(NR_CPUS)] = 0},
 	INIT_MM_CONTEXT(init_mm)
 };
_

Re: Build failures with gcc 4.5 and older

[Linus Torvalds]

On Tue, Aug 14, 2018 at 4:02 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> The m68k build still fails because 0cc3cd21657 ("cpu/hotplug: Boot HT
> siblings at least once") was evidently never tested on CONFIG_SMP=n.
> How could that come about - the patch is six weeks old??

Ehh, meet the joys of embargoes.

The code was tested (and people even found subtle arm64 problems due
to that testing), but because it couldn't be made public until today,
it didn't go through all the usual infrastructure we depend on.

But:

> kernel/cpu.c: In function 'boot_cpu_hotplug_init':
> kernel/cpu.c:2275:2: error: 'struct cpuhp_cpu_state' has no member named 'booted_once'

it should be fixed now in -git.

> @@ -490,6 +490,8 @@ struct mm_struct {
>  #endif
>         } __randomize_layout;
>
> +       int wibble;
> +

Can we call this something informative? Like

        int __gcc_4_4_is_garbage_that_shouldnt_be_used;

or something?

That is, if we actually want to really drag out this whole pointless
pain of allowing ancient compilers?

Guys, at some point we need to switch to 4.6. The people who feel the
pain today *will* feel the pain at some point. Just get it over with
already.

                  Linus

Re: Build failures with gcc 4.5 and older

[Guenter Roeck]

On 08/14/2018 04:20 PM, Linus Torvalds wrote:
> On Tue, Aug 14, 2018 at 4:02 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>>
>> The m68k build still fails because 0cc3cd21657 ("cpu/hotplug: Boot HT
>> siblings at least once") was evidently never tested on CONFIG_SMP=n.
>> How could that come about - the patch is six weeks old??
> 
> Ehh, meet the joys of embargoes.
> 
> The code was tested (and people even found subtle arm64 problems due
> to that testing), but because it couldn't be made public until today,
> it didn't go through all the usual infrastructure we depend on.
> 
> But:
> 
>> kernel/cpu.c: In function 'boot_cpu_hotplug_init':
>> kernel/cpu.c:2275:2: error: 'struct cpuhp_cpu_state' has no member named 'booted_once'
> 
> it should be fixed now in -git.
> 
>> @@ -490,6 +490,8 @@ struct mm_struct {
>>   #endif
>>          } __randomize_layout;
>>
>> +       int wibble;
>> +
> 
> Can we call this something informative? Like
> 
>          int __gcc_4_4_is_garbage_that_shouldnt_be_used;
> 
> or something?
> 
> That is, if we actually want to really drag out this whole pointless
> pain of allowing ancient compilers?
> 
> Guys, at some point we need to switch to 4.6. The people who feel the
> pain today *will* feel the pain at some point. Just get it over with
> already.
> 

For my part I am all for making gcc 4.6 mandatory.

Guenter

RE: Build failures with gcc 4.5 and older

[David Laight]

From: Guenter Roeck
> Sent: 14 August 2018 18:09
...
> Does that mean that gcc 4.5 and older are now officially no longer
> supported for compiling the kernel ?

Never mind the version of gcc, the x86 kernel doesn't build with the
default kernel options because the ORC unwinder hits a bug in libelf
(in objtool) that was only fixed late last year.

It isn't even obvious from the build log what has gone wrong.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: Build failures with gcc 4.5 and older

[Linus Torvalds]

On Wed, Aug 15, 2018 at 5:38 AM David Laight <David.Laight@aculab.com> wrote:
>
> Never mind the version of gcc, the x86 kernel doesn't build with the
> default kernel options because the ORC unwinder hits a bug in libelf
> (in objtool) that was only fixed late last year.
>
> It isn't even obvious from the build log what has gone wrong.

Can you give more details? We should try to work around it.

It's one thing to care about a compiler that is almost a decade old.
At some point we just have to let it go.

But some libelf bug that is less than a year old is likely to bite people.

                     Linus

Re: Build failures with gcc 4.5 and older

[Tony Luck]

On Tue, Aug 14, 2018 at 1:19 PM Tony Luck <tony.luck@gmail.com> wrote:
> My ia64 test box only has 4.3.4.  I seem to remember some pain points
> with newer versions of gcc on ia64. I need to poke around and find one
> new enough to get past this problem, but that still works for kernel building.

I had problems trying to build an up to date (or even a slightly old)
gcc starting from 4.3.4.

I did manage to build 4.6.4.

4.6.4 built git HEAD* that failed yesterday using 4.3.4. It boots OK.

-Tony

* 958f338e96f8 ("Merge branch 'l1tf-final' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")

RE: Build failures with gcc 4.5 and older

[David Laight]

From: Linus Torvalds
> Sent: 15 August 2018 16:44
> On Wed, Aug 15, 2018 at 5:38 AM David Laight <David.Laight@aculab.com> wrote:
> >
> > Never mind the version of gcc, the x86 kernel doesn't build with the
> > default kernel options because the ORC unwinder hits a bug in libelf
> > (in objtool) that was only fixed late last year.
> >
> > It isn't even obvious from the build log what has gone wrong.
> 
> Can you give more details? We should try to work around it.
> 
> It's one thing to care about a compiler that is almost a decade old.
> At some point we just have to let it go.
> 
> But some libelf bug that is less than a year old is likely to bite people.

See https://lkml.org/lkml/2017/9/10/186 for the libelf fix.
It isn't anything like as rare as those emails suggest.
An 'allmodconfig' build fails on a lot of object files after 4.15-rc9.

When I fell over the problem I found a few reports on the ubuntu lists
but they all just said the ubuntu version was unsupported.

There is this patch I did https://lkml.org/lkml/2018/7/26/266 that got
no comments.

But really something needs to be done to objtool.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: Build failures with gcc 4.5 and older

[Linus Torvalds]

On Wed, Aug 15, 2018 at 9:16 AM David Laight <David.Laight@aculab.com> wrote:
>
> >
> > But some libelf bug that is less than a year old is likely to bite people.
>
> See https://lkml.org/lkml/2017/9/10/186 for the libelf fix.
> It isn't anything like as rare as those emails suggest.
> An 'allmodconfig' build fails on a lot of object files after 4.15-rc9.

Ok, but that patch that fixes it was merged a long time ago already.
See commit 97dab2ae7e84 ("objtool: Fix object file corruption")

So I'm a bit confused by your issue. The thing you point to from last
year was literall fixed and committed to the tree in a couple of days
days.

> When I fell over the problem I found a few reports on the ubuntu lists
> but they all just said the ubuntu version was unsupported.
>
> There is this patch I did https://lkml.org/lkml/2018/7/26/266 that got
> no comments.
>
> But really something needs to be done to objtool.

I think you need to make a report about the exact problem with objtool
and your issue.

Not on the ubuntu lists, but to Josh.

             Linus

Re: Build failures with gcc 4.5 and older

[Linus Torvalds]

On Wed, Aug 15, 2018 at 9:09 AM Tony Luck <tony.luck@gmail.com> wrote:
>
> I did manage to build 4.6.4.
>
> 4.6.4 built git HEAD* that failed yesterday using 4.3.4. It boots OK.

Good. 4.6 is what we'd suggest be the new baseline, and we can
hopefully keep that for a while.

                  Linus

Re: Build failures with gcc 4.5 and older

[Guenter Roeck]

On Wed, Aug 15, 2018 at 09:09:17AM -0700, Tony Luck wrote:
> On Tue, Aug 14, 2018 at 1:19 PM Tony Luck <tony.luck@gmail.com> wrote:
> > My ia64 test box only has 4.3.4.  I seem to remember some pain points
> > with newer versions of gcc on ia64. I need to poke around and find one
> > new enough to get past this problem, but that still works for kernel building.
> 
> I had problems trying to build an up to date (or even a slightly old)
> gcc starting from 4.3.4.
> 

Ah yes, one of those little details: Older versions of gcc don't
build anymore with recent versions of gcc.

> I did manage to build 4.6.4.
> 
> 4.6.4 built git HEAD* that failed yesterday using 4.3.4. It boots OK.
> 
FWIW, I use gcc 8.1.0 (from kernel.org) for my ia64 test builds.
Of course, I have no idea if those builds actually create bootable images.

Guenter

Re: Build failures with gcc 4.5 and older

[Guenter Roeck]

On 08/15/2018 09:34 AM, Linus Torvalds wrote:
> On Wed, Aug 15, 2018 at 9:09 AM Tony Luck <tony.luck@gmail.com> wrote:
>>
>> I did manage to build 4.6.4.
>>
>> 4.6.4 built git HEAD* that failed yesterday using 4.3.4. It boots OK.
> 
> Good. 4.6 is what we'd suggest be the new baseline, and we can
> hopefully keep that for a while.
> 

So, just for the record, I stopped building (or, rather, I stopped trying
to build) unicore32 images for mainline and linux-next today.

Guenter

RE: Build failures with gcc 4.5 and older

[David Laight]

From: Linus Torvalds
> Sent: 15 August 2018 17:34
> To: David Laight
> Cc: Guenter Roeck; Linux Kernel Mailing List; Rik van Riel; Mike Galbraith; Dave Hansen; Andrew Morton
> Subject: Re: Build failures with gcc 4.5 and older
> 
> On Wed, Aug 15, 2018 at 9:16 AM David Laight <David.Laight@aculab.com> wrote:
> >
> > >
> > > But some libelf bug that is less than a year old is likely to bite people.
> >
> > See https://lkml.org/lkml/2017/9/10/186 for the libelf fix.
> > It isn't anything like as rare as those emails suggest.
> > An 'allmodconfig' build fails on a lot of object files after 4.15-rc9.
> 
> Ok, but that patch that fixes it was merged a long time ago already.
> See commit 97dab2ae7e84 ("objtool: Fix object file corruption")
> 
> So I'm a bit confused by your issue. The thing you point to from last
> year was literall fixed and committed to the tree in a couple of days
> days.

Hmmm... I still had to update from libelf-0.153.so to libelf-0.165.so
in order to get the output from objtool to be valid.
I'm sure I'd seen a patch to libelf as well.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: Build failures with gcc 4.5 and older

[Kees Cook]

On Tue, Aug 14, 2018 at 10:48 AM, Joe Perches <joe@perches.com> wrote:
> On Tue, 2018-08-14 at 10:09 -0700, Guenter Roeck wrote:
>> Hi,
>>
>> Since commit c1a2f7f0c0645 ("mm: Allocate the mm_cpumask
>> (mm->cpu_bitmap[]) dynamically based on nr_cpu_ids"), building
>> the Linux kernel with gcc version 4.5 and older fails as follows.
>>
>> In file included from ./include/linux/mm.h:17:0,
>>                  from ./include/linux/pid_namespace.h:7,
>>                from ./include/linux/ptrace.h:10,
>>                from arch/openrisc/kernel/asm-offsets.c:32:
>> ./include/linux/mm_types.h:497:16: error: flexible array member in otherwise empty struct
>>
>> This is just an example with gcc 4.5.1 for or32. I have seen the problem
>> with gcc 4.4 (for unicore32) as well.
>>
>> Does that mean that gcc 4.5 and older are now officially no longer
>> supported for compiling the kernel ?
>>
>> If so, would it make sense to update include/linux/compiler-gcc.h
>> accordingly ?
>
> And Documentation/process/changes.rst which shows a
> minimum version required of gcc as 3.2, etc...
>
> With cleaning up now unnecessary version tests in
> compiler-gcc.h, something like:

I rejoice at raising the minimum gcc to version 4.6! :)

> ---
>  Documentation/process/changes.rst |  2 +-
>  include/linux/compiler-gcc.h      | 86 ++++++++-------------------------------
>  2 files changed, 19 insertions(+), 69 deletions(-)

These look good, thanks:

Reviewed-by: Kees Cook <keescook@chromium.org>

-Kees

>
> diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> index 7a92a06f90de..61f918b10a0c 100644
> --- a/Documentation/process/changes.rst
> +++ b/Documentation/process/changes.rst
> @@ -29,7 +29,7 @@ you probably needn't concern yourself with isdn4k-utils.
>  ====================== ===============  ========================================
>          Program        Minimal version       Command to check the version
>  ====================== ===============  ========================================
> -GNU C                  3.2              gcc --version
> +GNU C                  4.6              gcc --version
>  GNU make               3.81             make --version
>  binutils               2.20             ld -v
>  flex                   2.5.35           flex --version
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 573f5a7d42d4..020e4b9eee5c 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -10,6 +10,10 @@
>                      + __GNUC_MINOR__ * 100     \
>                      + __GNUC_PATCHLEVEL__)
>
> +#if GCC_VERSION < 40600
> +# error Sorry, your compiler is too old - please upgrade it.
> +#endif
> +
>  /* Optimization barrier */
>
>  /* The "volatile" is due to gcc bugs */
> @@ -58,6 +62,12 @@
>  #define OPTIMIZER_HIDE_VAR(var)                                                \
>         __asm__ ("" : "=r" (var) : "0" (var))
>
> +/*
> + * A trick to suppress uninitialized variable warning without generating any
> + * code
> + */
> +#define uninitialized_var(x) x = x
> +
>  #ifdef __CHECKER__
>  #define __must_be_array(a)     0
>  #else
> @@ -91,7 +101,7 @@
>   * A lot of inline functions can cause havoc with function tracing.
>   */
>  #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) ||               \
> -    !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
> +    !defined(CONFIG_OPTIMIZE_INLINING)
>  #define inline \
>         inline __attribute__((always_inline, unused)) notrace __gnu_inline
>  #else
> @@ -148,47 +158,13 @@
>  #define __always_unused                __attribute__((unused))
>  #define __mode(x)               __attribute__((mode(x)))
>
> -/* gcc version specific checks */
> -
> -#if GCC_VERSION < 30200
> -# error Sorry, your compiler is too old - please upgrade it.
> -#endif
> -
> -#if GCC_VERSION < 30300
> -# define __used                        __attribute__((__unused__))
> -#else
> -# define __used                        __attribute__((__used__))
> -#endif
> -
> -#ifdef CONFIG_GCOV_KERNEL
> -# if GCC_VERSION < 30400
> -#   error "GCOV profiling support for gcc versions below 3.4 not included"
> -# endif /* __GNUC_MINOR__ */
> -#endif /* CONFIG_GCOV_KERNEL */
> -
> -#if GCC_VERSION >= 30400
>  #define __must_check           __attribute__((warn_unused_result))
>  #define __malloc               __attribute__((__malloc__))
> -#endif
> -
> -#if GCC_VERSION >= 40000
> -
> -/* GCC 4.1.[01] miscompiles __weak */
> -#ifdef __KERNEL__
> -# if GCC_VERSION >= 40100 &&  GCC_VERSION <= 40101
> -#  error Your version of gcc miscompiles the __weak directive
> -# endif
> -#endif
>
>  #define __used                 __attribute__((__used__))
>  #define __compiler_offsetof(a, b)                                      \
>         __builtin_offsetof(a, b)
>
> -#if GCC_VERSION >= 40100
> -# define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
> -#endif
> -
> -#if GCC_VERSION >= 40300
>  /* Mark functions as cold. gcc will assume any path leading to a call
>   * to them will be unlikely.  This means a lot of manual unlikely()s
>   * are unnecessary now for any paths leading to the usual suspects
> @@ -207,24 +183,19 @@
>
>  #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
>
> -#ifndef __CHECKER__
> -# define __compiletime_warning(message) __attribute__((warning(message)))
> -# define __compiletime_error(message) __attribute__((error(message)))
> -#endif /* __CHECKER__ */
> -#endif /* GCC_VERSION >= 40300 */
> -
> -#if GCC_VERSION >= 40400
>  #define __optimize(level)      __attribute__((__optimize__(level)))
>  #define __nostackprotector     __optimize("no-stack-protector")
> -#endif /* GCC_VERSION >= 40400 */
>
> -#if GCC_VERSION >= 40500
> +#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
>
>  #ifndef __CHECKER__
> +#define __compiletime_warning(message) __attribute__((warning(message)))
> +#define __compiletime_error(message) __attribute__((error(message)))
> +
>  #ifdef LATENT_ENTROPY_PLUGIN
>  #define __latent_entropy __attribute__((latent_entropy))
>  #endif
> -#endif
> +#endif /* __CHECKER__ */
>
>  /*
>   * calling noreturn functions, __builtin_unreachable() and __builtin_trap()
> @@ -262,10 +233,6 @@
>  #define randomized_struct_fields_end   } __randomize_layout;
>  #endif
>
> -#endif /* GCC_VERSION >= 40500 */
> -
> -#if GCC_VERSION >= 40600
> -
>  /*
>   * When used with Link Time Optimization, gcc can optimize away C functions or
>   * variables which are referenced only from assembly code.  __visible tells the
> @@ -274,8 +241,7 @@
>   */
>  #define __visible      __attribute__((externally_visible))
>
> -#endif /* GCC_VERSION >= 40600 */
> -
> +/* gcc version specific checks */
>
>  #if GCC_VERSION >= 40900 && !defined(__CHECKER__)
>  /*
> @@ -309,10 +275,8 @@
>   * folding in __builtin_bswap*() (yet), so don't set these for it.
>   */
>  #if defined(CONFIG_ARCH_USE_BUILTIN_BSWAP) && !defined(__CHECKER__)
> -#if GCC_VERSION >= 40400
>  #define __HAVE_BUILTIN_BSWAP32__
>  #define __HAVE_BUILTIN_BSWAP64__
> -#endif
>  #if GCC_VERSION >= 40800
>  #define __HAVE_BUILTIN_BSWAP16__
>  #endif
> @@ -341,10 +305,9 @@
>   * https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
>   */
>  #define __designated_init __attribute__((designated_init))
> +#define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
>  #endif
>
> -#endif /* gcc version >= 40000 specific checks */
> -
>  #if !defined(__noclone)
>  #define __noclone      /* not needed */
>  #endif
> @@ -353,16 +316,6 @@
>  #define __no_sanitize_address
>  #endif
>
> -/*
> - * A trick to suppress uninitialized variable warning without generating any
> - * code
> - */
> -#define uninitialized_var(x) x = x
> -
> -#if GCC_VERSION >= 50100
> -#define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
> -#endif
> -
>  /*
>   * Turn individual warnings and errors on and off locally, depending
>   * on version.
> @@ -375,12 +328,9 @@
>  #define __diag_GCC_warn                warning
>  #define __diag_GCC_error       error
>
> -/* Compilers before gcc-4.6 do not understand "#pragma GCC diagnostic push" */
> -#if GCC_VERSION >= 40600
>  #define __diag_str1(s)         #s
>  #define __diag_str(s)          __diag_str1(s)
>  #define __diag(s)              _Pragma(__diag_str(GCC diagnostic s))
> -#endif
>
>  #if GCC_VERSION >= 80000
>  #define __diag_GCC_8(s)                __diag(s)
>
>
>



-- 
Kees Cook
Pixel Security

Re: Build failures with gcc 4.5 and older

[Thomas Gleixner]

On Tue, 14 Aug 2018, Guenter Roeck wrote:
> On 08/14/2018 04:20 PM, Linus Torvalds wrote:
> > On Tue, Aug 14, 2018 at 4:02 PM Andrew Morton <akpm@linux-foundation.org>
> > wrote:
> > > 
> > > The m68k build still fails because 0cc3cd21657 ("cpu/hotplug: Boot HT
> > > siblings at least once") was evidently never tested on CONFIG_SMP=n.
> > > How could that come about - the patch is six weeks old??
> > 
> > Ehh, meet the joys of embargoes.
> > 
> > The code was tested (and people even found subtle arm64 problems due
> > to that testing), but because it couldn't be made public until today,
> > it didn't go through all the usual infrastructure we depend on.
> > 
> > But:
> > 
> > > kernel/cpu.c: In function 'boot_cpu_hotplug_init':
> > > kernel/cpu.c:2275:2: error: 'struct cpuhp_cpu_state' has no member named
> > > 'booted_once'
> > 
> > it should be fixed now in -git.
> > 
> > > @@ -490,6 +490,8 @@ struct mm_struct {
> > >   #endif
> > >          } __randomize_layout;
> > > 
> > > +       int wibble;
> > > +
> > 
> > Can we call this something informative? Like
> > 
> >          int __gcc_4_4_is_garbage_that_shouldnt_be_used;
> > 
> > or something?
> > 
> > That is, if we actually want to really drag out this whole pointless
> > pain of allowing ancient compilers?
> > 
> > Guys, at some point we need to switch to 4.6. The people who feel the
> > pain today *will* feel the pain at some point. Just get it over with
> > already.
> > 
> 
> For my part I am all for making gcc 4.6 mandatory.

No objections from my side.

Thanks,

	tglx

Re: Build failures with gcc 4.5 and older

[Arnd Bergmann]

On Mon, Aug 20, 2018 at 4:58 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Tue, 14 Aug 2018, Guenter Roeck wrote:
> >
> > For my part I am all for making gcc 4.6 mandatory.
>
> No objections from my side.

gcc-4.6 is also what I suggested a while ago as a good choice for a new minimum
version, back then I met some objection, but as time passes these probably got
less important:

https://lkml.org/lkml/2016/12/16/174

To recap the distros that I looked at back then using gcc older than
4.6, I found four:

 RHEL6: gcc-4.4
 Debian 6: gcc-4.4
 Ubuntu 10.04: gcc-4.4
 SLES11: gcc-4.3

The first three are all finally EOL as of this month, only SLES11 with gcc-4.3
is still supported in principle:

Service Pack Release                 FCS Date      General Ends    LTSS Ends
SUSE Linux Enterprise Server 11      24 Mar 2009   31 Dec 2010     N/A
SUSE Linux Enterprise Server 11 SP1  02 Jun 2010   31 Aug 2012     30 Aug 2015
SUSE Linux Enterprise Server 11 SP2  29 Feb 2012   31 Jan 2014     30 Jan 2017
SUSE Linux Enterprise Server 11 SP3  01 Jul 2013   31 Jan 2016     30 Jan 2019
SUSE Linux Enterprise Server 11 SP4  15 Jul 2015   31 Mar 2019     31 Mar 2022

However, installing the disro's SDK package on SLES11-SP3 brings it up to
gcc-4.7, or gcc-5.2 for SP4, so this is unlikely to cause much of a problem any
more.

I also have some ideas for cleanups that can be done now, in particular
to deal with compiler warnings.

      Arnd

Re: Build failures with gcc 4.5 and older

[Nick Desaulniers]

I think we should take Joe's patch.

Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>

(sorry for the lack of context, trying out the reply instructions from:
https://lore.kernel.org/lkml/4cdd4ab9ddd16f1fb168266643264595782fd890.camel@perches.com/)

Re: Build failures with gcc 4.5 and older

[Linus Torvalds]

On Mon, Aug 20, 2018 at 10:46 AM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> I think we should take Joe's patch.

I'll happily take Joe's patch and get the whole "ancient gcc versions"
issue behind us.

We'll come back to it in a few years when 4.6 is ancient too, but for
now we have no pressing need not to support it.

Joe - proper commit message and sign-off?

                  Linus