diff mbox

Support gcc 6 for building

Message ID 1429127143-31745-1-git-send-email-andi@firstfloor.org (mailing list archive)
State New, archived
Headers show

Commit Message

Andi Kleen April 15, 2015, 7:45 p.m. UTC
From: Andi Kleen <ak@linux.intel.com>

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 <segher@kernel.crashing.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
 include/linux/compiler-gcc.h | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

Comments

Segher Boessenkool April 16, 2015, 3:04 a.m. UTC | #1
On Wed, Apr 15, 2015 at 12:45:43PM -0700, Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
> 
> 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 <segher@kernel.crashing.org>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>

Tested-by: Segher Boessenkool <segher@kernel.crashing.org>

This works fine, thanks,


Segher
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Michal Marek April 16, 2015, 7:57 a.m. UTC | #2
On 2015-04-15 21:45, Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
> 
> 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.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andi Kleen April 16, 2015, 3:56 p.m. UTC | #3
On Thu, Apr 16, 2015 at 09:57:48AM +0200, Michal Marek wrote:
> On 2015-04-15 21:45, Andi Kleen wrote:
> > From: Andi Kleen <ak@linux.intel.com>
> > 
> > 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.
> 
> 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
Joe Perches April 16, 2015, 4:23 p.m. UTC | #4
On Thu, 2015-04-16 at 17:56 +0200, Andi Kleen wrote:
> On Thu, Apr 16, 2015 at 09:57:48AM +0200, Michal Marek wrote:
> > On 2015-04-15 21:45, Andi Kleen wrote:
> > > From: Andi Kleen <ak@linux.intel.com>
> > > 
> > > 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.
> > 
> > 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andi Kleen April 16, 2015, 4:29 p.m. UTC | #5
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Michal Marek April 16, 2015, 8:13 p.m. UTC | #6
Dne 16.4.2015 v 17:56 Andi Kleen napsal(a):
> On Thu, Apr 16, 2015 at 09:57:48AM +0200, Michal Marek wrote:
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Joe Perches April 16, 2015, 8:31 p.m. UTC | #7
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
Andrew Morton April 20, 2015, 9:17 p.m. UTC | #8
On Thu, 16 Apr 2015 13:31:01 -0700 Joe Perches <joe@perches.com> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andi Kleen April 20, 2015, 9:24 p.m. UTC | #9
On Mon, Apr 20, 2015 at 02:17:13PM -0700, Andrew Morton wrote:
> On Thu, 16 Apr 2015 13:31:01 -0700 Joe Perches <joe@perches.com> 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.
> 
> 
> 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
>
diff mbox

Patch

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index cdf13ca..9c9a4e4 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -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 */