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
On Tue, Aug 14, 2018 at 10:09 AM Guenter Roeck <[email protected]> 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
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)
On Tue, Aug 14, 2018 at 10:20:32AM -0700, Linus Torvalds wrote:
> On Tue, Aug 14, 2018 at 10:09 AM Guenter Roeck <[email protected]> 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
On Tue, Aug 14, 2018 at 11:02 AM Guenter Roeck <[email protected]> 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 <[email protected]> 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
On Tue, 14 Aug 2018 10:09:04 -0700 Guenter Roeck <[email protected]> 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?
On Tue, Aug 14, 2018 at 02:36:55PM -0700, Andrew Morton wrote:
> On Tue, 14 Aug 2018 10:09:04 -0700 Guenter Roeck <[email protected]> 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
On Tue, 14 Aug 2018 15:15:59 -0700 Guenter Roeck <[email protected]> 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)
};
_
On Tue, Aug 14, 2018 at 4:02 PM Andrew Morton <[email protected]> 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
On 08/14/2018 04:20 PM, Linus Torvalds wrote:
> On Tue, Aug 14, 2018 at 4:02 PM Andrew Morton <[email protected]> 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
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)
On Wed, Aug 15, 2018 at 5:38 AM David Laight <[email protected]> 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
On Tue, Aug 14, 2018 at 1:19 PM Tony Luck <[email protected]> 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")
From: Linus Torvalds
> Sent: 15 August 2018 16:44
> On Wed, Aug 15, 2018 at 5:38 AM David Laight <[email protected]> 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)
On Wed, Aug 15, 2018 at 9:16 AM David Laight <[email protected]> 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
On Wed, Aug 15, 2018 at 9:09 AM Tony Luck <[email protected]> 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
On Wed, Aug 15, 2018 at 09:09:17AM -0700, Tony Luck wrote:
> On Tue, Aug 14, 2018 at 1:19 PM Tony Luck <[email protected]> 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
On 08/15/2018 09:34 AM, Linus Torvalds wrote:
> On Wed, Aug 15, 2018 at 9:09 AM Tony Luck <[email protected]> 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
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 <[email protected]> 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)
On Tue, Aug 14, 2018 at 10:48 AM, Joe Perches <[email protected]> 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 <[email protected]>
-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
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 <[email protected]>
> > 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
On Mon, Aug 20, 2018 at 4:58 PM Thomas Gleixner <[email protected]> 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
I think we should take Joe's patch.
Reviewed-by: Nick Desaulniers <[email protected]>
(sorry for the lack of context, trying out the reply instructions from:
https://lore.kernel.org/lkml/[email protected]/)
On Mon, Aug 20, 2018 at 10:46 AM Nick Desaulniers
<[email protected]> 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