All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] kernel: add support for gcc 5
@ 2014-09-04 15:37 Sasha Levin
  2014-09-04 21:12 ` Andrew Morton
  2014-09-04 21:25 ` Aaro Koskinen
  0 siblings, 2 replies; 17+ messages in thread
From: Sasha Levin @ 2014-09-04 15:37 UTC (permalink / raw)
  To: akpm; +Cc: mingo, linux-kernel, Sasha Levin

We're missing include/linux/compiler-gcc5.h which is required now
because gcc branched off to v5 in trunk.

Just copy the relevant bits out of include/linux/compiler-gcc4.h,
no new code is added as of now.

This fixes a build error when using gcc 5.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
---
 include/linux/compiler-gcc5.h |   66 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)
 create mode 100644 include/linux/compiler-gcc5.h

diff --git a/include/linux/compiler-gcc5.h b/include/linux/compiler-gcc5.h
new file mode 100644
index 0000000..b989d55
--- /dev/null
+++ b/include/linux/compiler-gcc5.h
@@ -0,0 +1,66 @@
+#ifndef __LINUX_COMPILER_H
+#error "Please don't include <linux/compiler-gcc5.h> directly, include <linux/compiler.h> instead."
+#endif
+
+#define __used			__attribute__((__used__))
+#define __must_check 		__attribute__((warn_unused_result))
+#define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
+
+/* 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__ */
+
+/*
+ * 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__))
+
+/*
+ * Tell the optimizer that something else uses this function or variable.
+ */
+#define __visible __attribute__((externally_visible))
+
+/*
+ * 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.
+ * Fixed in GCC 4.8.2 and later versions.
+ *
+ * (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
+#define __HAVE_BUILTIN_BSWAP32__
+#define __HAVE_BUILTIN_BSWAP64__
+#define __HAVE_BUILTIN_BSWAP16__
+#endif /* CONFIG_ARCH_USE_BUILTIN_BSWAP */
-- 
1.7.10.4


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH] kernel: add support for gcc 5
  2014-09-04 15:37 [PATCH] kernel: add support for gcc 5 Sasha Levin
@ 2014-09-04 21:12 ` Andrew Morton
  2014-09-04 21:19   ` Richard Weinberger
  2014-09-04 21:25 ` Aaro Koskinen
  1 sibling, 1 reply; 17+ messages in thread
From: Andrew Morton @ 2014-09-04 21:12 UTC (permalink / raw)
  To: Sasha Levin; +Cc: mingo, linux-kernel, stable, Greg KH

On Thu,  4 Sep 2014 11:37:19 -0400 Sasha Levin <sasha.levin@oracle.com> wrote:

> We're missing include/linux/compiler-gcc5.h which is required now
> because gcc branched off to v5 in trunk.
> 
> Just copy the relevant bits out of include/linux/compiler-gcc4.h,
> no new code is added as of now.
> 
> This fixes a build error when using gcc 5.

I think I'll stick a cc:stable on this one, as people will presumably
wish to compile older kernels with newer gcc's at some time in the
future.


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] kernel: add support for gcc 5
  2014-09-04 21:12 ` Andrew Morton
@ 2014-09-04 21:19   ` Richard Weinberger
  2014-09-04 21:25     ` Andrew Morton
  0 siblings, 1 reply; 17+ messages in thread
From: Richard Weinberger @ 2014-09-04 21:19 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Sasha Levin, Ingo Molnar, LKML, stable, Greg KH, Hannes Frederic Sowa

On Thu, Sep 4, 2014 at 11:12 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Thu,  4 Sep 2014 11:37:19 -0400 Sasha Levin <sasha.levin@oracle.com> wrote:
>
>> We're missing include/linux/compiler-gcc5.h which is required now
>> because gcc branched off to v5 in trunk.
>>
>> Just copy the relevant bits out of include/linux/compiler-gcc4.h,
>> no new code is added as of now.
>>
>> This fixes a build error when using gcc 5.
>
> I think I'll stick a cc:stable on this one, as people will presumably
> wish to compile older kernels with newer gcc's at some time in the
> future.

CC'ing Hannes, he sent a much simpler gcc5 patch a few days ago.
https://lkml.org/lkml/2014/8/26/710

-- 
Thanks,
//richard

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] kernel: add support for gcc 5
  2014-09-04 21:19   ` Richard Weinberger
@ 2014-09-04 21:25     ` Andrew Morton
  2014-09-04 21:38       ` Sasha Levin
  2014-09-05 15:04       ` H. Peter Anvin
  0 siblings, 2 replies; 17+ messages in thread
From: Andrew Morton @ 2014-09-04 21:25 UTC (permalink / raw)
  To: Richard Weinberger
  Cc: Sasha Levin, Ingo Molnar, LKML, stable, Greg KH, Hannes Frederic Sowa

On Thu, 4 Sep 2014 23:19:34 +0200 Richard Weinberger <richard.weinberger@gmail.com> wrote:

> On Thu, Sep 4, 2014 at 11:12 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Thu,  4 Sep 2014 11:37:19 -0400 Sasha Levin <sasha.levin@oracle.com> wrote:
> >
> >> We're missing include/linux/compiler-gcc5.h which is required now
> >> because gcc branched off to v5 in trunk.
> >>
> >> Just copy the relevant bits out of include/linux/compiler-gcc4.h,
> >> no new code is added as of now.
> >>
> >> This fixes a build error when using gcc 5.
> >
> > I think I'll stick a cc:stable on this one, as people will presumably
> > wish to compile older kernels with newer gcc's at some time in the
> > future.
> 
> CC'ing Hannes, he sent a much simpler gcc5 patch a few days ago.
> https://lkml.org/lkml/2014/8/26/710

That approach won't last for long - as soon as we add some
gcc5-specific thing, we'll need a new file.

Let history be a guide:

diff -u include/linux/compiler-gcc3.h include/linux/compiler-gcc4.h

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] kernel: add support for gcc 5
  2014-09-04 15:37 [PATCH] kernel: add support for gcc 5 Sasha Levin
  2014-09-04 21:12 ` Andrew Morton
@ 2014-09-04 21:25 ` Aaro Koskinen
  2014-09-04 21:32   ` Sasha Levin
  2014-09-04 22:43   ` Hannes Frederic Sowa
  1 sibling, 2 replies; 17+ messages in thread
From: Aaro Koskinen @ 2014-09-04 21:25 UTC (permalink / raw)
  To: Sasha Levin; +Cc: akpm, mingo, linux-kernel

On Thu, Sep 04, 2014 at 11:37:19AM -0400, Sasha Levin wrote:
> We're missing include/linux/compiler-gcc5.h which is required now
> because gcc branched off to v5 in trunk.
> 
> Just copy the relevant bits out of include/linux/compiler-gcc4.h,
> no new code is added as of now.
> 
> This fixes a build error when using gcc 5.

With the new GCC version numbering scheme, does this mean there will
be a new such file to be added every year? Maybe this could be handled
some other way?

A.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] kernel: add support for gcc 5
  2014-09-04 21:25 ` Aaro Koskinen
@ 2014-09-04 21:32   ` Sasha Levin
  2014-09-04 22:43   ` Hannes Frederic Sowa
  1 sibling, 0 replies; 17+ messages in thread
From: Sasha Levin @ 2014-09-04 21:32 UTC (permalink / raw)
  To: Aaro Koskinen; +Cc: akpm, mingo, linux-kernel

On 09/04/2014 05:25 PM, Aaro Koskinen wrote:
> On Thu, Sep 04, 2014 at 11:37:19AM -0400, Sasha Levin wrote:
>> We're missing include/linux/compiler-gcc5.h which is required now
>> because gcc branched off to v5 in trunk.
>>
>> Just copy the relevant bits out of include/linux/compiler-gcc4.h,
>> no new code is added as of now.
>>
>> This fixes a build error when using gcc 5.
> 
> With the new GCC version numbering scheme, does this mean there will
> be a new such file to be added every year? Maybe this could be handled
> some other way?

One big file would be a huge mess.

I think that if it starts getting out of hand we can move them into
their own folder, something like:

	include/linux/compiler/gcc/gccX.h


Thanks,
Sasha

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] kernel: add support for gcc 5
  2014-09-04 21:25     ` Andrew Morton
@ 2014-09-04 21:38       ` Sasha Levin
  2014-09-05 15:04       ` H. Peter Anvin
  1 sibling, 0 replies; 17+ messages in thread
From: Sasha Levin @ 2014-09-04 21:38 UTC (permalink / raw)
  To: Andrew Morton, Richard Weinberger
  Cc: Ingo Molnar, LKML, stable, Greg KH, Hannes Frederic Sowa

On 09/04/2014 05:25 PM, Andrew Morton wrote:
> On Thu, 4 Sep 2014 23:19:34 +0200 Richard Weinberger <richard.weinberger@gmail.com> wrote:
> 
>> On Thu, Sep 4, 2014 at 11:12 PM, Andrew Morton
>> <akpm@linux-foundation.org> wrote:
>>> On Thu,  4 Sep 2014 11:37:19 -0400 Sasha Levin <sasha.levin@oracle.com> wrote:
>>>
>>>> We're missing include/linux/compiler-gcc5.h which is required now
>>>> because gcc branched off to v5 in trunk.
>>>>
>>>> Just copy the relevant bits out of include/linux/compiler-gcc4.h,
>>>> no new code is added as of now.
>>>>
>>>> This fixes a build error when using gcc 5.
>>>
>>> I think I'll stick a cc:stable on this one, as people will presumably
>>> wish to compile older kernels with newer gcc's at some time in the
>>> future.
>>
>> CC'ing Hannes, he sent a much simpler gcc5 patch a few days ago.
>> https://lkml.org/lkml/2014/8/26/710
> 
> That approach won't last for long - as soon as we add some
> gcc5-specific thing, we'll need a new file.
> 
> Let history be a guide:
> 
> diff -u include/linux/compiler-gcc3.h include/linux/compiler-gcc4.h

I didn't see Hannes version before sending mine, apologies for that.

Right now something in gcc5 seems to be broken since my test VMs refuse
to even load up their *very* trivial userspace properly (/bin/bash just
hangs) so I suspect we'll have changes to that file even before the first
official version of gcc5 is out.


Thanks,
Sasha


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] kernel: add support for gcc 5
  2014-09-04 21:25 ` Aaro Koskinen
  2014-09-04 21:32   ` Sasha Levin
@ 2014-09-04 22:43   ` Hannes Frederic Sowa
  2014-09-04 23:47     ` Joe Perches
  1 sibling, 1 reply; 17+ messages in thread
From: Hannes Frederic Sowa @ 2014-09-04 22:43 UTC (permalink / raw)
  To: Aaro Koskinen, Sasha Levin; +Cc: akpm, mingo, linux-kernel

Hello,

On Thu, Sep 4, 2014, at 23:25, Aaro Koskinen wrote:
> On Thu, Sep 04, 2014 at 11:37:19AM -0400, Sasha Levin wrote:
> > We're missing include/linux/compiler-gcc5.h which is required now
> > because gcc branched off to v5 in trunk.
> > 
> > Just copy the relevant bits out of include/linux/compiler-gcc4.h,
> > no new code is added as of now.
> > 
> > This fixes a build error when using gcc 5.
> 
> With the new GCC version numbering scheme, does this mean there will
> be a new such file to be added every year? Maybe this could be handled
> some other way?

I agree, with the new gcc roadmap announced back in August [1] they tend
to increase the major number with each yearly release. I don't think it
is feasable to add a new header every year in a timely manner.

Most statements are already depending on GCC_VERSION, maybe we can just
unify all gcc specific headers to one, still trying to keep the file
organized? ;)

[1] https://gcc.gnu.org/develop.html (Section "Version Numbering Scheme
for GCC 5 and Up")

Bye,
Hannes

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] kernel: add support for gcc 5
  2014-09-04 22:43   ` Hannes Frederic Sowa
@ 2014-09-04 23:47     ` Joe Perches
  2014-09-05  3:37       ` Sasha Levin
  0 siblings, 1 reply; 17+ messages in thread
From: Joe Perches @ 2014-09-04 23:47 UTC (permalink / raw)
  To: Hannes Frederic Sowa
  Cc: Aaro Koskinen, Sasha Levin, akpm, mingo, linux-kernel

On Fri, 2014-09-05 at 00:43 +0200, Hannes Frederic Sowa wrote:
> Most statements are already depending on GCC_VERSION, maybe we can just
> unify all gcc specific headers to one, still trying to keep the file
> organized? ;)

Maybe something like:

gnu development of gcc will be more frequent and the use of
compiler-gcc<major>.h likely will not be convenient anymore.

Integrate the individual compiler-gcc<major>.h files into
compiler-gcc.h.
---
 include/linux/compiler-gcc.h  | 113 ++++++++++++++++++++++++++++++++++++++++--
 include/linux/compiler-gcc3.h |  23 ---------
 include/linux/compiler-gcc4.h |  88 --------------------------------
 3 files changed, 109 insertions(+), 115 deletions(-)
 delete mode 100644 include/linux/compiler-gcc3.h
 delete mode 100644 include/linux/compiler-gcc4.h

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 02ae99e..ec73109 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -100,10 +100,115 @@
 #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.
+ * Fixed in GCC 4.8.2 and later versions.
+ *
+ * (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 */
+
+#endif	/* gcc version specific checks */
 
 #if !defined(__noclone)
 #define __noclone	/* not needed */
diff --git a/include/linux/compiler-gcc3.h b/include/linux/compiler-gcc3.h
deleted file mode 100644
index 7d89feb..0000000
--- a/include/linux/compiler-gcc3.h
+++ /dev/null
@@ -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 */
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
deleted file mode 100644
index 2507fd2..0000000
--- a/include/linux/compiler-gcc4.h
+++ /dev/null
@@ -1,88 +0,0 @@
-#ifndef __LINUX_COMPILER_H
-#error "Please don't include <linux/compiler-gcc4.h> directly, include <linux/compiler.h> instead."
-#endif
-
-/* 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 __must_check 		__attribute__((warn_unused_result))
-#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.
- * Fixed in GCC 4.8.2 and later versions.
- *
- * (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 */
-- 
1.8.1.2.459.gbcd45b4.dirty




^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH] kernel: add support for gcc 5
  2014-09-04 23:47     ` Joe Perches
@ 2014-09-05  3:37       ` Sasha Levin
  2014-09-05  3:58         ` Joe Perches
  2014-09-05  4:08         ` Hannes Frederic Sowa
  0 siblings, 2 replies; 17+ messages in thread
From: Sasha Levin @ 2014-09-05  3:37 UTC (permalink / raw)
  To: Joe Perches, Hannes Frederic Sowa
  Cc: Aaro Koskinen, akpm, mingo, linux-kernel

On 09/04/2014 07:47 PM, Joe Perches wrote:
> On Fri, 2014-09-05 at 00:43 +0200, Hannes Frederic Sowa wrote:
>> > Most statements are already depending on GCC_VERSION, maybe we can just
>> > unify all gcc specific headers to one, still trying to keep the file
>> > organized? ;)
> Maybe something like:
> 
> gnu development of gcc will be more frequent and the use of
> compiler-gcc<major>.h likely will not be convenient anymore.
> 
> Integrate the individual compiler-gcc<major>.h files into
> compiler-gcc.h.

Please no. We have a similar file we maintain in our team that's supposed to
do something very similar for kernel versions. It goes all the way back to
2.6.9 and it's a *horrible* mess.

This is how compiler-gcc.h will end up looking in a while.


Thanks,
Sasha

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] kernel: add support for gcc 5
  2014-09-05  3:37       ` Sasha Levin
@ 2014-09-05  3:58         ` Joe Perches
  2014-09-05  4:08         ` Hannes Frederic Sowa
  1 sibling, 0 replies; 17+ messages in thread
From: Joe Perches @ 2014-09-05  3:58 UTC (permalink / raw)
  To: Sasha Levin
  Cc: Hannes Frederic Sowa, Aaro Koskinen, akpm, mingo, linux-kernel

On Thu, 2014-09-04 at 23:37 -0400, Sasha Levin wrote:
> On 09/04/2014 07:47 PM, Joe Perches wrote:
> > On Fri, 2014-09-05 at 00:43 +0200, Hannes Frederic Sowa wrote:
> >> > Most statements are already depending on GCC_VERSION, maybe we can just
> >> > unify all gcc specific headers to one, still trying to keep the file
> >> > organized? ;)
> > Maybe something like:
> > 
> > gnu development of gcc will be more frequent and the use of
> > compiler-gcc<major>.h likely will not be convenient anymore.
> > 
> > Integrate the individual compiler-gcc<major>.h files into
> > compiler-gcc.h.
> 
> Please no. We have a similar file we maintain in our team that's supposed to
> do something very similar for kernel versions. It goes all the way back to
> 2.6.9 and it's a *horrible* mess.
> 
> This is how compiler-gcc.h will end up looking in a while.

As gcc options are generally upward compatible,
I don't think it will but there's no great way
to predict the future.

It wouldn't be as complicated as say backports.



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] kernel: add support for gcc 5
  2014-09-05  3:37       ` Sasha Levin
  2014-09-05  3:58         ` Joe Perches
@ 2014-09-05  4:08         ` Hannes Frederic Sowa
  2014-09-05 14:44           ` Sasha Levin
  1 sibling, 1 reply; 17+ messages in thread
From: Hannes Frederic Sowa @ 2014-09-05  4:08 UTC (permalink / raw)
  To: Sasha Levin; +Cc: Joe Perches, Aaro Koskinen, akpm, mingo, linux-kernel

On Do, 2014-09-04 at 23:37 -0400, Sasha Levin wrote:
> On 09/04/2014 07:47 PM, Joe Perches wrote:
> > On Fri, 2014-09-05 at 00:43 +0200, Hannes Frederic Sowa wrote:
> >> > Most statements are already depending on GCC_VERSION, maybe we can just
> >> > unify all gcc specific headers to one, still trying to keep the file
> >> > organized? ;)
> > Maybe something like:
> > 
> > gnu development of gcc will be more frequent and the use of
> > compiler-gcc<major>.h likely will not be convenient anymore.
> > 
> > Integrate the individual compiler-gcc<major>.h files into
> > compiler-gcc.h.
> 
> Please no. We have a similar file we maintain in our team that's supposed to
> do something very similar for kernel versions. It goes all the way back to
> 2.6.9 and it's a *horrible* mess.
> 
> This is how compiler-gcc.h will end up looking in a while.

Something along these lines? We can make '4' a macro describing it
references the latest possible compiler-gccX.h file.

--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -103,7 +103,12 @@
 #define __gcc_header(x) #x
 #define _gcc_header(x) __gcc_header(linux/compiler-gcc##x.h)
 #define gcc_header(x) _gcc_header(x)
+
+#if __GNUC__ > 4
+#include gcc_header(4)
+#else
 #include gcc_header(__GNUC__)
+#endif
 
 #if !defined(__noclone)
 #define __noclone      /* not needed */


I still think we should start chaining newer gcc header files to
deduplicate the content. What do you think?

Bye,
Hannes



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] kernel: add support for gcc 5
  2014-09-05  4:08         ` Hannes Frederic Sowa
@ 2014-09-05 14:44           ` Sasha Levin
  2014-09-05 20:39             ` [PATCH] gcc: clamp gcc version to most highest specific header version available Hannes Frederic Sowa
  0 siblings, 1 reply; 17+ messages in thread
From: Sasha Levin @ 2014-09-05 14:44 UTC (permalink / raw)
  To: Hannes Frederic Sowa
  Cc: Joe Perches, Aaro Koskinen, akpm, mingo, linux-kernel

On 09/05/2014 12:08 AM, Hannes Frederic Sowa wrote:
> On Do, 2014-09-04 at 23:37 -0400, Sasha Levin wrote:
>> > On 09/04/2014 07:47 PM, Joe Perches wrote:
>>> > > On Fri, 2014-09-05 at 00:43 +0200, Hannes Frederic Sowa wrote:
>>>>> > >> > Most statements are already depending on GCC_VERSION, maybe we can just
>>>>> > >> > unify all gcc specific headers to one, still trying to keep the file
>>>>> > >> > organized? ;)
>>> > > Maybe something like:
>>> > > 
>>> > > gnu development of gcc will be more frequent and the use of
>>> > > compiler-gcc<major>.h likely will not be convenient anymore.
>>> > > 
>>> > > Integrate the individual compiler-gcc<major>.h files into
>>> > > compiler-gcc.h.
>> > 
>> > Please no. We have a similar file we maintain in our team that's supposed to
>> > do something very similar for kernel versions. It goes all the way back to
>> > 2.6.9 and it's a *horrible* mess.
>> > 
>> > This is how compiler-gcc.h will end up looking in a while.
> Something along these lines? We can make '4' a macro describing it
> references the latest possible compiler-gccX.h file.

I agree, something along those lines would be great. We'd still have
all this mess split into smaller headers and we won't be forced to add
compiler-gccX.h until we actually need it.

The problem it causes is that if you want to figure out what specific line
of code in one of those headers affects your kernel you may need to browse
through multiple headers (-gcc3.h ... -gccX.h) but I suspect that we won't
have too many conflicting declarations, as Joe pointed out - they are mostly
upward compatible.


Thanks,
Sasha

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] kernel: add support for gcc 5
  2014-09-04 21:25     ` Andrew Morton
  2014-09-04 21:38       ` Sasha Levin
@ 2014-09-05 15:04       ` H. Peter Anvin
  1 sibling, 0 replies; 17+ messages in thread
From: H. Peter Anvin @ 2014-09-05 15:04 UTC (permalink / raw)
  To: Andrew Morton, Richard Weinberger
  Cc: Sasha Levin, Ingo Molnar, LKML, stable, Greg KH, Hannes Frederic Sowa

On 09/04/2014 02:25 PM, Andrew Morton wrote:
>>
>> CC'ing Hannes, he sent a much simpler gcc5 patch a few days ago.
>> https://lkml.org/lkml/2014/8/26/710
> 
> That approach won't last for long - as soon as we add some
> gcc5-specific thing, we'll need a new file.
> 
> Let history be a guide:
> 
> diff -u include/linux/compiler-gcc3.h include/linux/compiler-gcc4.h

It seems much saner to do that branching when we actually need to.  In
the meantime I suspect that a handful of redefinitions would actually be
cleaner.

	-hpa



^ permalink raw reply	[flat|nested] 17+ messages in thread

* [PATCH] gcc: clamp gcc version to most highest specific header version available
  2014-09-05 14:44           ` Sasha Levin
@ 2014-09-05 20:39             ` Hannes Frederic Sowa
  2014-09-05 21:09               ` Joe Perches
  0 siblings, 1 reply; 17+ messages in thread
From: Hannes Frederic Sowa @ 2014-09-05 20:39 UTC (permalink / raw)
  To: linux-kernel
  Cc: Aaro Koskinen, Sasha Levin, akpm, mingo, H. Peter Anvin,
	Joe Perches, Richard Weinberger

As announced in [1] gcc will increase its major number yearly but we don't
need to include gcc version specific quirks for every version normally.

This patch allows to compile every kernel with all new versions of gcc
without adding a specific compiler-gccX.h header. We do so by clamping
the __GNUC__ version to the most specific version dependent header file.

If someone adds a new gccX.h file __GCC_CLAMP_VERSION_HEADER also needs
to be modified.

The decision if chained including of header files (e.g. gcc5.h includes
gcc4.h) is necessary or should be avoided can be postponed until more
experience in using the official gcc release is gained.

Tested with gcc4 and gcc5.

[1] https://gcc.gnu.org/develop.html#num_scheme

Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: akpm@linuxfoundation.org
Cc: mingo@kernel.org
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Joe Perches <joe@perches.com>
Cc: Richard Weinberger <richard.weinberger@gmail.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
 include/linux/{compiler-gcc.h => compiler-gcc/gcc.h}   | 12 ++++++++++--
 include/linux/{compiler-gcc3.h => compiler-gcc/gcc3.h} |  0
 include/linux/{compiler-gcc4.h => compiler-gcc/gcc4.h} |  0
 include/linux/compiler.h                               |  2 +-
 4 files changed, 11 insertions(+), 3 deletions(-)
 rename include/linux/{compiler-gcc.h => compiler-gcc/gcc.h} (91%)
 rename include/linux/{compiler-gcc3.h => compiler-gcc/gcc3.h} (100%)
 rename include/linux/{compiler-gcc4.h => compiler-gcc/gcc4.h} (100%)

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc/gcc.h
similarity index 91%
rename from include/linux/compiler-gcc.h
rename to include/linux/compiler-gcc/gcc.h
index 02ae99e..0681fa3 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc/gcc.h
@@ -1,5 +1,5 @@
 #ifndef __LINUX_COMPILER_H
-#error "Please don't include <linux/compiler-gcc.h> directly, include <linux/compiler.h> instead."
+#error "Please don't include <linux/compiler-gcc/gcc.h> directly, include <linux/compiler.h> instead."
 #endif
 
 /*
@@ -101,9 +101,17 @@
 #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(linux/compiler-gcc/gcc##x.h)
 #define gcc_header(x) _gcc_header(x)
+
+/* increase this if you add a new compiler-gcc/gccX.h header file */
+#define __GCC_CLAMP_VERSION_HEADER 4
+
+#if __GNUC__ > __GCC_CLAMP_VERSION_HEADER
+#include gcc_header(__GCC_CLAMP_VERSION_HEADER)
+#else
 #include gcc_header(__GNUC__)
+#endif
 
 #if !defined(__noclone)
 #define __noclone	/* not needed */
diff --git a/include/linux/compiler-gcc3.h b/include/linux/compiler-gcc/gcc3.h
similarity index 100%
rename from include/linux/compiler-gcc3.h
rename to include/linux/compiler-gcc/gcc3.h
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc/gcc4.h
similarity index 100%
rename from include/linux/compiler-gcc4.h
rename to include/linux/compiler-gcc/gcc4.h
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index d5ad7b1..06be28b 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -51,7 +51,7 @@ extern void __chk_io_ptr(const volatile void __iomem *);
 #ifdef __KERNEL__
 
 #ifdef __GNUC__
-#include <linux/compiler-gcc.h>
+#include <linux/compiler-gcc/gcc.h>
 #endif
 
 #define notrace __attribute__((no_instrument_function))
-- 
1.9.3


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH] gcc: clamp gcc version to most highest specific header version available
  2014-09-05 20:39             ` [PATCH] gcc: clamp gcc version to most highest specific header version available Hannes Frederic Sowa
@ 2014-09-05 21:09               ` Joe Perches
  2014-09-05 22:38                 ` Hannes Frederic Sowa
  0 siblings, 1 reply; 17+ messages in thread
From: Joe Perches @ 2014-09-05 21:09 UTC (permalink / raw)
  To: Hannes Frederic Sowa
  Cc: linux-kernel, Aaro Koskinen, Sasha Levin, akpm, mingo,
	H. Peter Anvin, Richard Weinberger

On Fri, 2014-09-05 at 22:39 +0200, Hannes Frederic Sowa wrote:
> As announced in [1] gcc will increase its major number yearly but we don't
> need to include gcc version specific quirks for every version normally.
> 
> This patch allows to compile every kernel with all new versions of gcc
> without adding a specific compiler-gccX.h header. We do so by clamping
> the __GNUC__ version to the most specific version dependent header file.
> 
> If someone adds a new gccX.h file __GCC_CLAMP_VERSION_HEADER also needs
> to be modified.
> 
> The decision if chained including of header files (e.g. gcc5.h includes
> gcc4.h) is necessary or should be avoided can be postponed until more
> experience in using the official gcc release is gained.

I think the churn rate in the gcc compiler specific
#include headers will be low enough that a single
combined file should be acceptable.

Keeping all the gcc #defines together seems more
readable to me.

The trivial integration I did eliminated one
duplicate #define as well as that hack for
#include gcc_header(__GNUC__)





^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] gcc: clamp gcc version to most highest specific header version available
  2014-09-05 21:09               ` Joe Perches
@ 2014-09-05 22:38                 ` Hannes Frederic Sowa
  0 siblings, 0 replies; 17+ messages in thread
From: Hannes Frederic Sowa @ 2014-09-05 22:38 UTC (permalink / raw)
  To: Joe Perches
  Cc: linux-kernel, Aaro Koskinen, Sasha Levin, akpm, mingo,
	H. Peter Anvin, Richard Weinberger

On Fr, 2014-09-05 at 14:09 -0700, Joe Perches wrote:
> On Fri, 2014-09-05 at 22:39 +0200, Hannes Frederic Sowa wrote:
> > As announced in [1] gcc will increase its major number yearly but we don't
> > need to include gcc version specific quirks for every version normally.
> > 
> > This patch allows to compile every kernel with all new versions of gcc
> > without adding a specific compiler-gccX.h header. We do so by clamping
> > the __GNUC__ version to the most specific version dependent header file.
> > 
> > If someone adds a new gccX.h file __GCC_CLAMP_VERSION_HEADER also needs
> > to be modified.
> > 
> > The decision if chained including of header files (e.g. gcc5.h includes
> > gcc4.h) is necessary or should be avoided can be postponed until more
> > experience in using the official gcc release is gained.
> 
> I think the churn rate in the gcc compiler specific
> #include headers will be low enough that a single
> combined file should be acceptable.
> 
> Keeping all the gcc #defines together seems more
> readable to me.
> 
> The trivial integration I did eliminated one
> duplicate #define as well as that hack for
> #include gcc_header(__GNUC__)

It's just a proposal and I don't have a strong opinion on that. I just
want to make sure it is easy to compile current kernel with a gcc
released in two years. ;)

Bye,
Hannes



^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2014-09-05 22:38 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-04 15:37 [PATCH] kernel: add support for gcc 5 Sasha Levin
2014-09-04 21:12 ` Andrew Morton
2014-09-04 21:19   ` Richard Weinberger
2014-09-04 21:25     ` Andrew Morton
2014-09-04 21:38       ` Sasha Levin
2014-09-05 15:04       ` H. Peter Anvin
2014-09-04 21:25 ` Aaro Koskinen
2014-09-04 21:32   ` Sasha Levin
2014-09-04 22:43   ` Hannes Frederic Sowa
2014-09-04 23:47     ` Joe Perches
2014-09-05  3:37       ` Sasha Levin
2014-09-05  3:58         ` Joe Perches
2014-09-05  4:08         ` Hannes Frederic Sowa
2014-09-05 14:44           ` Sasha Levin
2014-09-05 20:39             ` [PATCH] gcc: clamp gcc version to most highest specific header version available Hannes Frederic Sowa
2014-09-05 21:09               ` Joe Perches
2014-09-05 22:38                 ` Hannes Frederic Sowa

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.