Message ID | 1429127143-31745-1-git-send-email-andi@firstfloor.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
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
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
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
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
> 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
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 (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
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
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 --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 */