Skip to contentSkip to conversation

Support gcc 6 for building

PATCH In review Andi Kleen 5 participants 13 messages Apr 15, 2015 – Apr 20, 2015 Kbuild

lore
Share & tools
lore

Andi Kleen

author
#0 lore raw

PATCH 1/1 Support gcc 6 for building

From: Andi Kleen <[email protected]>

gcc recently switched to a new version number scheme, where every version gets a new major version number. The current version is 5.x, the next 6.x, etc.

The gcc git repository trunk branch just switched to report 6.x for the next major release.

This breaks the way Linux selects compiler-gccX.h based on the major version. Every new version would require adding a new compiler-gccX.h file, which wouldn't really scale.

Let's assume that future gccs are fairly compatible (they are unlikely to break anything Linux is relying on). So we can just keep using compiler-gcc5.h, and select any specific differences with #if.

Cc Segher Boessenkool <[email protected]>
---
 include/linux/compiler-gcc.h | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
include/linux/compiler-gcc.h +6 -1
index cdf13ca..9c9a4e4 100644
@@ -104,7 +104,12 @@
 #define __gcc_header(x) #x
 #define _gcc_header(x) __gcc_header(linux/compiler-gcc##x.h)
 #define gcc_header(x) _gcc_header(x)
-#include gcc_header(__GNUC__)
+#if __GNUC__ < 5
+#define __LINUX_GCC_VERSION __GNUC__
+#else
+#define __LINUX_GCC_VERSION 5
+#endif
+#include gcc_header(__LINUX_GCC_VERSION)
 
 #if !defined(__noclone)
 #define __noclone	/* not needed */
Signature · 1 line
2.3.3
Tested-by on v1 1/1
#1 lore raw
Quoted 12 lines · Andi Kleen

From: Andi Kleen <[email protected]>

gcc recently switched to a new version number scheme, where every version gets a new major version number. The current version is 5.x, the next 6.x, etc.

The gcc git repository trunk branch just switched to report 6.x for the next major release.

This breaks the way Linux selects compiler-gccX.h based on the major version. Every new version would require adding a new compiler-gccX.h file, which wouldn't really scale.

Quoted 6 lines

Let's assume that future gccs are fairly compatible (they are unlikely to break anything Linux is relying on). So we can just keep using compiler-gcc5.h, and select any specific differences with #if.

Cc Segher Boessenkool <[email protected]>

This works fine, thanks,

Segher

#2 lore raw
In reply to Andi Kleen
Quoted 8 lines · Andi Kleen

From: Andi Kleen <[email protected]>

gcc recently switched to a new version number scheme, where every version gets a new major version number. The current version is 5.x, the next 6.x, etc.

The gcc git repository trunk branch just switched to report 6.x for the next major release.

Quoted 7 lines

This breaks the way Linux selects compiler-gccX.h based on the major version. Every new version would require adding a new compiler-gccX.h file, which wouldn't really scale.

Let's assume that future gccs are fairly compatible (they are unlikely to break anything Linux is relying on). So we can just keep using compiler-gcc5.h, and select any specific differences with #if.

Good idea. With the new scheme, we could also merge back compiler-gcc5.h and compiler-gcc4.h. The only difference is the KASAN_ABI_VERSION define.

Michal

author
#3 lore raw
Quoted 13 lines · Michal Marek
Quoted 12 lines · Andi Kleen

From: Andi Kleen <[email protected]>

gcc recently switched to a new version number scheme, where every version gets a new major version number. The current version is 5.x, the next 6.x, etc.

The gcc git repository trunk branch just switched to report 6.x for the next major release.

This breaks the way Linux selects compiler-gccX.h based on the major version. Every new version would require adding a new compiler-gccX.h file, which wouldn't really scale.

Quoted 6 lines
Quoted 3 lines

Let's assume that future gccs are fairly compatible (they are unlikely to break anything Linux is relying on). So we can just keep using compiler-gcc5.h, and select any specific differences with #if.

Good idea. With the new scheme, we could also merge back compiler-gcc5.h and compiler-gcc4.h. The only difference is the KASAN_ABI_VERSION define.

Would be fine too. Are you doing that, or should I send a patch?

-Andi

Signature · 1 line
[email protected] -- Speaking for myself only.
#4 lore raw
Quoted 14 lines · Andi Kleen
Quoted 13 lines · Michal Marek
Quoted 12 lines · Andi Kleen

From: Andi Kleen <[email protected]>

gcc recently switched to a new version number scheme, where every version gets a new major version number. The current version is 5.x, the next 6.x, etc.

The gcc git repository trunk branch just switched to report 6.x for the next major release.

This breaks the way Linux selects compiler-gccX.h based on the major version. Every new version would require adding a new compiler-gccX.h file, which wouldn't really scale.

Quoted 8 lines
Quoted 6 lines
Quoted 3 lines

Let's assume that future gccs are fairly compatible (they are unlikely to break anything Linux is relying on). So we can just keep using compiler-gcc5.h, and select any specific differences with #if.

Good idea. With the new scheme, we could also merge back compiler-gcc5.h and compiler-gcc4.h. The only difference is the KASAN_ABI_VERSION define.

Would be fine too. Are you doing that, or should I send a patch?

As compiler-gcc3.h is trivial, what about integrating the whole thing into a single file and get rid of the compiler-gcc<version>.h files?

That would deduplicate the __must_check and __used macros.

I added Sasha Levin to the cc's as he was the only complainant the first time I suggested this.

https://lkml.org/lkml/2014/9/4/675

author
#5 lore raw
Quoted 3 lines

As compiler-gcc3.h is trivial, what about integrating the whole thing into a single file and get rid of the compiler-gcc<version>.h files?

I think that's the right thing to do yes.

-Andi

#6 lore raw

cover Integrate compiler-gcc[345].h files into compiler-gcc.h

Joe Perches (2):
compiler-gcc.h: Neatening
compiler-gcc: Integrate the various compiler-gcc[345].h files

 include/linux/compiler-gcc.h  | 207 +++++++++++++++++++++++++++++++++---------
 include/linux/compiler-gcc3.h |  23 -----
 include/linux/compiler-gcc4.h |  91 -------------------
 include/linux/compiler-gcc5.h |  67 --------------
 4 files changed, 162 insertions(+), 226 deletions(-)
 delete mode 100644 include/linux/compiler-gcc3.h
 delete mode 100644 include/linux/compiler-gcc4.h
 delete mode 100644 include/linux/compiler-gcc5.h
Signature · 1 line
2.1.2
#7 lore raw

Re: [PATCH 0/2] Integrate compiler-gcc[345].h files into compiler-gcc.h

Quoted 4 lines · On Thu, 16 Apr 2015 13:31:01 -0700 Joe Perches <[email protected]> wrote:

Joe Perches (2):
compiler-gcc.h: Neatening
compiler-gcc: Integrate the various compiler-gcc[345].h files

We have at least three support-three-gcc-6 patchsets floating about. Are we all happy with Joe's patchset?

I expect Andi's
http://ozlabs.org/~akpm/mmots/broken-out/lto-add-__noreorder-and-mark-initcalls-__noreorder.patch
will need to be updated in response, which is why I didn't merge it.

author
#8 lore raw

Re: [PATCH 0/2] Integrate compiler-gcc[345].h files into compiler-gcc.h

Quoted 9 lines · Andrew Morton
Quoted 4 lines · On Thu, 16 Apr 2015 13:31:01 -0700 Joe Perches <[email protected]> wrote:

Joe Perches (2):
compiler-gcc.h: Neatening
compiler-gcc: Integrate the various compiler-gcc[345].h files

We have at least three support-three-gcc-6 patchsets floating about. Are we all happy with Joe's patchset?

It's fine for me.

Quoted 5 lines

I expect Andi's
http://ozlabs.org/~akpm/mmots/broken-out/lto-add-__noreorder-and-mark-initcalls-__noreorder.patch
will need to be updated in response, which is why I didn't merge it.

I'll resend.

-Andi

Quoted 1 line
Signature · 1 line
[email protected] -- Speaking for myself only.
#9 lore raw

PATCH 1/2 compiler-gcc.h: Neatening

In reply to Andi Kleen

Move the inline and noinline blocks together Comment neatening
Alignment of __attribute__ uses
Consistent naming of __must_be_array macro argument Multiline macro neatening

---
 include/linux/compiler-gcc.h | 85 +++++++++++++++++++++++---------------------
 1 file changed, 45 insertions(+), 40 deletions(-)
include/linux/compiler-gcc.h +45 -40
index cdf13ca..0b008ad 100644
@@ -5,9 +5,9 @@
 /*
  * Common definitions for all gcc versions go here.
  */
-#define GCC_VERSION (__GNUC__ * 10000 \
-		   + __GNUC_MINOR__ * 100 \
-		   + __GNUC_PATCHLEVEL__)
+#define GCC_VERSION (__GNUC__ * 10000		\
+		     + __GNUC_MINOR__ * 100	\
+		     + __GNUC_PATCHLEVEL__)
 
 
 /* Optimization barrier */
@@ -32,55 +32,63 @@
  * the inline assembly constraint from =g to =r, in this particular
  * case either is valid.
  */
-#define RELOC_HIDE(ptr, off)					\
-  ({ unsigned long __ptr;					\
-    __asm__ ("" : "=r"(__ptr) : "0"(ptr));		\
-    (typeof(ptr)) (__ptr + (off)); })
+#define RELOC_HIDE(ptr, off)						\
+({									\
+	unsigned long __ptr;						\
+	__asm__ ("" : "=r"(__ptr) : "0"(ptr));				\
+	(typeof(ptr)) (__ptr + (off));					\
+})
 
 /* Make the optimizer believe the variable can be manipulated arbitrarily. */
-#define OPTIMIZER_HIDE_VAR(var) __asm__ ("" : "=r" (var) : "0" (var))
+#define OPTIMIZER_HIDE_VAR(var)						\
+	__asm__ ("" : "=r" (var) : "0" (var))
 
 #ifdef __CHECKER__
-#define __must_be_array(arr) 0
+#define __must_be_array(a)	0
 #else
 /* &a[0] degrades to a pointer: a different type from an array */
-#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
+#define __must_be_array(a)	BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
 #endif
 
 /*
  * Force always-inline if the user requests it so via the .config,
  * or if gcc is too old:
  */
-#if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \
+#if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) ||		\
     !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
-# define inline		inline		__attribute__((always_inline)) notrace
-# define __inline__	__inline__	__attribute__((always_inline)) notrace
-# define __inline	__inline	__attribute__((always_inline)) notrace
+#define inline		inline		__attribute__((always_inline)) notrace
+#define __inline__	__inline__	__attribute__((always_inline)) notrace
+#define __inline	__inline	__attribute__((always_inline)) notrace
 #else
 /* A lot of inline functions can cause havoc with function tracing */
-# define inline		inline		notrace
-# define __inline__	__inline__	notrace
-# define __inline	__inline	notrace
+#define inline		inline		notrace
+#define __inline__	__inline__	notrace
+#define __inline	__inline	notrace
 #endif
 
-#define __deprecated			__attribute__((deprecated))
-#define __packed			__attribute__((packed))
-#define __weak				__attribute__((weak))
-#define __alias(symbol)		__attribute__((alias(#symbol)))
+#define __always_inline	inline __attribute__((always_inline))
+#define  noinline	__attribute__((noinline))
+
+#define __deprecated	__attribute__((deprecated))
+#define __packed	__attribute__((packed))
+#define __weak		__attribute__((weak))
+#define __alias(symbol)	__attribute__((alias(#symbol)))
 
 /*
- * it doesn't make sense on ARM (currently the only user of __naked) to trace
- * naked functions because then mcount is called without stack and frame pointer
- * being set up and there is no chance to restore the lr register to the value
- * before mcount was called.
+ * it doesn't make sense on ARM (currently the only user of __naked)
+ * to trace naked functions because then mcount is called without
+ * stack and frame pointer being set up and there is no chance to
+ * restore the lr register to the value before mcount was called.
+ *
+ * The asm() bodies of naked functions often depend on standard calling
+ * conventions, therefore they must be noinline and noclone.
  *
- * The asm() bodies of naked functions often depend on standard calling conventions,
- * therefore they must be noinline and noclone.  GCC 4.[56] currently fail to enforce
- * this, so we must do so ourselves.  See GCC PR44290.
+ * GCC 4.[56] currently fail to enforce this, so we must do so ourselves.
+ * See GCC PR44290.
  */
-#define __naked				__attribute__((naked)) noinline __noclone notrace
+#define __naked		__attribute__((naked)) noinline __noclone notrace
 
-#define __noreturn			__attribute__((noreturn))
+#define __noreturn	__attribute__((noreturn))
 
 /*
  * From the GCC manual:
@@ -92,14 +100,13 @@
  * would be.
  * [...]
  */
-#define __pure				__attribute__((pure))
-#define __aligned(x)			__attribute__((aligned(x)))
-#define __printf(a, b)			__attribute__((format(printf, a, b)))
-#define __scanf(a, b)			__attribute__((format(scanf, a, b)))
-#define  noinline			__attribute__((noinline))
-#define __attribute_const__		__attribute__((__const__))
-#define __maybe_unused			__attribute__((unused))
-#define __always_unused			__attribute__((unused))
+#define __pure			__attribute__((pure))
+#define __aligned(x)		__attribute__((aligned(x)))
+#define __printf(a, b)		__attribute__((format(printf, a, b)))
+#define __scanf(a, b)		__attribute__((format(scanf, a, b)))
+#define __attribute_const__	__attribute__((__const__))
+#define __maybe_unused		__attribute__((unused))
+#define __always_unused		__attribute__((unused))
 
 #define __gcc_header(x) #x
 #define _gcc_header(x) __gcc_header(linux/compiler-gcc##x.h)
@@ -115,5 +122,3 @@
  * code
  */
 #define uninitialized_var(x) x = x
-
-#define __always_inline		inline __attribute__((always_inline))
Signature · 1 line
2.1.2
#10 lore raw

Re: [PATCH 1/2] compiler-gcc.h: Neatening

Quoted 5 lines · Joe Perches

Move the inline and noinline blocks together Comment neatening
Alignment of __attribute__ uses
Consistent naming of __must_be_array macro argument Multiline macro neatening

I must have missed the -s flag on the git commit.

#11 lore raw

PATCH 2/2 compiler-gcc: Integrate the various compiler-gcc[345].h files

In reply to Andi Kleen

As gcc major version numbers are going to advance rather rapidly in the future, there's no real value in separate files for each compiler version.

Deduplicate some of the macros #defined in each file too.

Neaten comments using normal kernel commenting style

---
 include/linux/compiler-gcc.h  | 120 ++++++++++++++++++++++++++++++++++++++++--
 include/linux/compiler-gcc3.h |  23 --------
 include/linux/compiler-gcc4.h |  91 --------------------------------
 include/linux/compiler-gcc5.h |  67 -----------------------
 4 files changed, 116 insertions(+), 185 deletions(-)
 delete mode 100644 include/linux/compiler-gcc3.h
 delete mode 100644 include/linux/compiler-gcc4.h
 delete mode 100644 include/linux/compiler-gcc5.h
include/linux/compiler-gcc.h +116 -4
index 0b008ad..e28b089 100644
@@ -108,10 +108,122 @@
 #define __maybe_unused		__attribute__((unused))
 #define __always_unused		__attribute__((unused))
 
-#define __gcc_header(x) #x
-#define _gcc_header(x) __gcc_header(linux/compiler-gcc##x.h)
-#define gcc_header(x) _gcc_header(x)
-#include gcc_header(__GNUC__)
+/* 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))
+#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 && GCC_VERSION < 40600
+# 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
+ * like BUG(), printk(), panic() etc. [but let's keep them for now for
+ * older compilers]
+ *
+ * Early snapshots of gcc 4.3 don't support this and we can't detect this
+ * in the preprocessor, but we can live with this because they're unreleased.
+ * Maketime probing would be overkill here.
+ *
+ * gcc also has a __attribute__((__hot__)) to move hot functions into
+ * a special section, but I don't see any sense in this right now in
+ * the kernel context
+ */
+#define __cold			__attribute__((__cold__))
+
+#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 >= 40500
+/*
+ * Mark a position in code as unreachable.  This can be used to
+ * suppress control flow warnings after asm blocks that transfer
+ * control elsewhere.
+ *
+ * Early snapshots of gcc 4.5 don't support this and we can't detect
+ * this in the preprocessor, but we can live with this because they're
+ * unreleased.  Really, we need to have autoconf for the kernel.
+ */
+#define unreachable() __builtin_unreachable()
+
+/* Mark a function definition as prohibited from being cloned. */
+#define __noclone	__attribute__((__noclone__))
+
+#endif /* GCC_VERSION >= 40500 */
+
+#if GCC_VERSION >= 40600
+/*
+ * Tell the optimizer that something else uses this function or variable.
+ */
+#define __visible	__attribute__((externally_visible))
+#endif
+
+/*
+ * GCC 'asm goto' miscompiles certain code sequences:
+ *
+ *   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
+ *
+ * Work it around via a compiler barrier quirk suggested by Jakub Jelinek.
+ *
+ * (asm goto is automatically volatile - the naming reflects this.)
+ */
+#define asm_volatile_goto(x...)	do { asm goto(x); asm (""); } while (0)
+
+#ifdef CONFIG_ARCH_USE_BUILTIN_BSWAP
+#if GCC_VERSION >= 40400
+#define __HAVE_BUILTIN_BSWAP32__
+#define __HAVE_BUILTIN_BSWAP64__
+#endif
+#if GCC_VERSION >= 40800 || (defined(__powerpc__) && GCC_VERSION >= 40600)
+#define __HAVE_BUILTIN_BSWAP16__
+#endif
+#endif /* CONFIG_ARCH_USE_BUILTIN_BSWAP */
+
+#if GCC_VERSION >= 50000
+#define KASAN_ABI_VERSION 4
+#elif GCC_VERSION >= 40902
+#define KASAN_ABI_VERSION 3
+#endif
+
+#endif	/* gcc version >= 40000 specific checks */
 
 #if !defined(__noclone)
 #define __noclone	/* not needed */
include/linux/compiler-gcc3.h deleted +0 -23
deleted file mode 100644
index 7d89feb..0000000
@@ -1,23 +0,0 @@
-#ifndef __LINUX_COMPILER_H
-#error "Please don't include <linux/compiler-gcc3.h> directly, include <linux/compiler.h> instead."
-#endif
-
-#if GCC_VERSION < 30200
-# error Sorry, your compiler is too old - please upgrade it.
-#endif
-
-#if GCC_VERSION >= 30300
-# define __used			__attribute__((__used__))
-#else
-# define __used			__attribute__((__unused__))
-#endif
-
-#if GCC_VERSION >= 30400
-#define __must_check		__attribute__((warn_unused_result))
-#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 */
include/linux/compiler-gcc4.h deleted +0 -91

91 lines not on this page · raw message

include/linux/compiler-gcc5.h deleted +0 -67

67 lines not on this page · raw message

Signature · 1 line
2.1.2
#12 lore raw
In reply to Andi Kleen

Dne 16.4.2015 v 17:56 Andi Kleen napsal(a):

Quoted 5 lines · Michal Marek
Quoted 2 lines

Good idea. With the new scheme, we could also merge back compiler-gcc5.h and compiler-gcc4.h. The only difference is the KASAN_ABI_VERSION define.

Would be fine too. Are you doing that, or should I send a patch?

I suggest to merge your patch now, so that the kernel can be built with gcc 6 snapshots. I can send a follow-up patch.

Michal