| Message ID | 20180607204927.219329-2-ndesaulniers@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Jun 7, 2018 at 10:49 PM, Nick Desaulniers <ndesaulniers@google.com> wrote: > Functions marked extern inline do not emit an externally visible > function when the gnu89 C standard is used. Some KBUILD Makefiles > overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without > an explicit C standard specified, the default is gnu11. Since c99, the > semantics of extern inline have changed such that an externally visible > function is always emitted. This can lead to multiple definition errors > of extern inline functions at link time of compilation units whose build > files have removed an explicit C standard compiler flag for users of GCC > 5.1+ or Clang. > > Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> > Suggested-by: H. Peter Anvin <hpa@zytor.com> > Suggested-by: Joe Perches <joe@perches.com> I suspect this will break Geert's gcc-4.1.2, which I think doesn't have that attribute yet (4.1.3 or higher have it according to the documentation. It wouldn't be hard to work around that if we want to keep that version working, or we could decide that it's time to officially stop supporting that version, but we should probably decide on one or the other. Arnd -- 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 Fri, Jun 8, 2018 at 9:59 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Thu, Jun 7, 2018 at 10:49 PM, Nick Desaulniers > <ndesaulniers@google.com> wrote: >> Functions marked extern inline do not emit an externally visible >> function when the gnu89 C standard is used. Some KBUILD Makefiles >> overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without >> an explicit C standard specified, the default is gnu11. Since c99, the >> semantics of extern inline have changed such that an externally visible >> function is always emitted. This can lead to multiple definition errors >> of extern inline functions at link time of compilation units whose build >> files have removed an explicit C standard compiler flag for users of GCC >> 5.1+ or Clang. >> >> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> >> Suggested-by: H. Peter Anvin <hpa@zytor.com> >> Suggested-by: Joe Perches <joe@perches.com> > > I suspect this will break Geert's gcc-4.1.2, which I think doesn't have that > attribute yet (4.1.3 or higher have it according to the documentation. > > It wouldn't be hard to work around that if we want to keep that version > working, or we could decide that it's time to officially stop supporting > that version, but we should probably decide on one or the other. > Good point. What is the minimum requirement of GCC version currently? AFAICS x86/asm-goto support requires GCC >= 4.5? Just FYI... ...saw the last days in upstream commits that kbuild/kconfig for 4.18-rc1 offers possibilities to check for cc-version dependencies. - sed@ - -- 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 Fri, Jun 08, 2018 at 12:04:36PM +0200, Sedat Dilek wrote: > On Fri, Jun 8, 2018 at 9:59 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > On Thu, Jun 7, 2018 at 10:49 PM, Nick Desaulniers > > <ndesaulniers@google.com> wrote: > >> Functions marked extern inline do not emit an externally visible > >> function when the gnu89 C standard is used. Some KBUILD Makefiles > >> overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without > >> an explicit C standard specified, the default is gnu11. Since c99, the > >> semantics of extern inline have changed such that an externally visible > >> function is always emitted. This can lead to multiple definition errors > >> of extern inline functions at link time of compilation units whose build > >> files have removed an explicit C standard compiler flag for users of GCC > >> 5.1+ or Clang. > >> > >> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> > >> Suggested-by: H. Peter Anvin <hpa@zytor.com> > >> Suggested-by: Joe Perches <joe@perches.com> > > > > I suspect this will break Geert's gcc-4.1.2, which I think doesn't have that > > attribute yet (4.1.3 or higher have it according to the documentation. > > > > It wouldn't be hard to work around that if we want to keep that version > > working, or we could decide that it's time to officially stop supporting > > that version, but we should probably decide on one or the other. > > > > Good point. > What is the minimum requirement of GCC version currently? Good question ;-) (I recently had the impression that Documentation/process/changes.rst was making fun of me ;-) > AFAICS x86/asm-goto support requires GCC >= 4.5? > > Just FYI... > ...saw the last days in upstream commits that kbuild/kconfig for > 4.18-rc1 offers possibilities to check for cc-version dependencies. Good to know! Mind retrieving/sharing the commit id(s) or links to the corresponding discussion on LKML? Thanks, Andrea > > - sed@ - -- 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 Fri, Jun 8, 2018 at 1:28 PM, Andrea Parri <andrea.parri@amarulasolutions.com> wrote: > On Fri, Jun 08, 2018 at 12:04:36PM +0200, Sedat Dilek wrote: >> On Fri, Jun 8, 2018 at 9:59 AM, Arnd Bergmann <arnd@arndb.de> wrote: >> > On Thu, Jun 7, 2018 at 10:49 PM, Nick Desaulniers >> > <ndesaulniers@google.com> wrote: >> >> Functions marked extern inline do not emit an externally visible >> >> function when the gnu89 C standard is used. Some KBUILD Makefiles >> >> overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without >> >> an explicit C standard specified, the default is gnu11. Since c99, the >> >> semantics of extern inline have changed such that an externally visible >> >> function is always emitted. This can lead to multiple definition errors >> >> of extern inline functions at link time of compilation units whose build >> >> files have removed an explicit C standard compiler flag for users of GCC >> >> 5.1+ or Clang. >> >> >> >> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> >> >> Suggested-by: H. Peter Anvin <hpa@zytor.com> >> >> Suggested-by: Joe Perches <joe@perches.com> >> > >> > I suspect this will break Geert's gcc-4.1.2, which I think doesn't have that >> > attribute yet (4.1.3 or higher have it according to the documentation. >> > >> > It wouldn't be hard to work around that if we want to keep that version >> > working, or we could decide that it's time to officially stop supporting >> > that version, but we should probably decide on one or the other. >> > >> >> Good point. >> What is the minimum requirement of GCC version currently? > > Good question ;-) (I recently had the impression that > Documentation/process/changes.rst was making fun of me ;-) > > >> AFAICS x86/asm-goto support requires GCC >= 4.5? >> >> Just FYI... >> ...saw the last days in upstream commits that kbuild/kconfig for >> 4.18-rc1 offers possibilities to check for cc-version dependencies. > > Good to know! Mind retrieving/sharing the commit id(s) > or links to the corresponding discussion on LKML? > Sorry, it is not yet in Linus upstream. see [1]. Documentation: kconfig: add recommended way to describe compiler support kconfig: add CC_IS_CLANG and CLANG_VERSION kconfig: add CC_IS_GCC and GCC_VERSION - sed@ - [1] https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/log/?h=kbuild -- 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 Fri, Jun 8, 2018 at 3:04 AM Sedat Dilek <sedat.dilek@gmail.com> wrote: > > On Fri, Jun 8, 2018 at 9:59 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > On Thu, Jun 7, 2018 at 10:49 PM, Nick Desaulniers > > <ndesaulniers@google.com> wrote: > >> Functions marked extern inline do not emit an externally visible > >> function when the gnu89 C standard is used. Some KBUILD Makefiles > >> overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without > >> an explicit C standard specified, the default is gnu11. Since c99, the > >> semantics of extern inline have changed such that an externally visible > >> function is always emitted. This can lead to multiple definition errors > >> of extern inline functions at link time of compilation units whose build > >> files have removed an explicit C standard compiler flag for users of GCC > >> 5.1+ or Clang. > >> > >> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> > >> Suggested-by: H. Peter Anvin <hpa@zytor.com> > >> Suggested-by: Joe Perches <joe@perches.com> > > > > I suspect this will break Geert's gcc-4.1.2, which I think doesn't have that > > attribute yet (4.1.3 or higher have it according to the documentation. > > > > It wouldn't be hard to work around that if we want to keep that version > > working, or we could decide that it's time to officially stop supporting > > that version, but we should probably decide on one or the other. Heh, so earlier we decided against compiler flags (-std=gnu89 or -fgnu89-inline) in preference to function attributes. The function attribute is preferable as some of the Makefiles [accidentally?] overwrite KBUILD_CFLAGS, which is problematic for gcc 5.1 users as the implicit c standard used was changed to gnu11 from gnu89. What's nice is that to support gcc 4.1 users, we simply don't need to add any attribute, as their implicit c standard is gnu89 which has the semantics for extern inline that we want. I have a simple change to this patch that can support users of various gcc versions, see below: > Good point. > What is the minimum requirement of GCC version currently? > AFAICS x86/asm-goto support requires GCC >= 4.5? Yes, but that's only for x86, IIUC. It seems the kernel may have different minimum required versions of GCC based on arch then? That may be ok, but I'm not sure that's easy to keep track of without having it explicitly stated somewhere like the docs perhaps? > Just FYI... > ...saw the last days in upstream commits that kbuild/kconfig for > 4.18-rc1 offers possibilities to check for cc-version dependencies. Those will be helpful. If we want to pursue compiler flags, which get set some Makefiles, then yes. But I think a simpler change to my patch would be as below. It seems gcc did not get __has_attribute [0] until 5.1, but will define __GNUC_GNU_INLINE__ if supported. [1] Unfortunately, Clang does not define __GNUC_GNU_INLINE__ [2]. So a proper feature test might look like: ``` #ifndef __has_attribute #define __has_attribute(x) 0 #endif #if defined(__GNUC_GNU_INLINE__) || __has_attribute(gnu_inline) #define __gnu_inline __attribute__(gnu_inline) #endif #define inline inline __attribute__((always_inline, unused)) notrace __gnu_inline ``` Thoughts on this approach? I can send a v5 tomorrow if there's no major issues. Feedback appreciated, as always. [0] https://clang.llvm.org/docs/LanguageExtensions.html#has-attribute [1] https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes [2] https://bugs.llvm.org/show_bug.cgi?id=37784
<caoj.fnst@cn.fujitsu.com>,Greg KH <gregkh@linuxfoundation.org>,jarkko.sakkinen@linux.intel.com,jgross@suse.com,Josh Poimboeuf <jpoimboe@redhat.com>,Matthias Kaehlcke <mka@chromium.org>,thomas.lendacky@amd.com,Thiebaud Weksteen <tweek@google.com>,mjg59@google.com,joe@perches.com From: hpa@zytor.com Message-ID: <191E4EBE-4CB2-4C8B-AB61-689A91FFE7A8@zytor.com> On June 12, 2018 11:33:14 AM PDT, Nick Desaulniers <ndesaulniers@google.com> wrote: >On Fri, Jun 8, 2018 at 3:04 AM Sedat Dilek <sedat.dilek@gmail.com> >wrote: >> >> On Fri, Jun 8, 2018 at 9:59 AM, Arnd Bergmann <arnd@arndb.de> wrote: >> > On Thu, Jun 7, 2018 at 10:49 PM, Nick Desaulniers >> > <ndesaulniers@google.com> wrote: >> >> Functions marked extern inline do not emit an externally visible >> >> function when the gnu89 C standard is used. Some KBUILD Makefiles >> >> overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as >without >> >> an explicit C standard specified, the default is gnu11. Since c99, >the >> >> semantics of extern inline have changed such that an externally >visible >> >> function is always emitted. This can lead to multiple definition >errors >> >> of extern inline functions at link time of compilation units whose >build >> >> files have removed an explicit C standard compiler flag for users >of GCC >> >> 5.1+ or Clang. >> >> >> >> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> >> >> Suggested-by: H. Peter Anvin <hpa@zytor.com> >> >> Suggested-by: Joe Perches <joe@perches.com> >> > >> > I suspect this will break Geert's gcc-4.1.2, which I think doesn't >have that >> > attribute yet (4.1.3 or higher have it according to the >documentation. >> > >> > It wouldn't be hard to work around that if we want to keep that >version >> > working, or we could decide that it's time to officially stop >supporting >> > that version, but we should probably decide on one or the other. > >Heh, so earlier we decided against compiler flags (-std=gnu89 or >-fgnu89-inline) in preference to function attributes. The function >attribute is preferable as some of the Makefiles [accidentally?] >overwrite KBUILD_CFLAGS, which is problematic for gcc 5.1 users as the >implicit c standard used was changed to gnu11 from gnu89. What's nice >is that to support gcc 4.1 users, we simply don't need to add any >attribute, as their implicit c standard is gnu89 which has the >semantics for extern inline that we want. I have a simple change to >this patch that can support users of various gcc versions, see below: > >> Good point. >> What is the minimum requirement of GCC version currently? >> AFAICS x86/asm-goto support requires GCC >= 4.5? > >Yes, but that's only for x86, IIUC. It seems the kernel may have >different minimum required versions of GCC based on arch then? That >may be ok, but I'm not sure that's easy to keep track of without >having it explicitly stated somewhere like the docs perhaps? > >> Just FYI... >> ...saw the last days in upstream commits that kbuild/kconfig for >> 4.18-rc1 offers possibilities to check for cc-version dependencies. > >Those will be helpful. If we want to pursue compiler flags, which get >set some Makefiles, then yes. But I think a simpler change to my >patch would be as below. > >It seems gcc did not get __has_attribute [0] until 5.1, but will >define __GNUC_GNU_INLINE__ if supported. [1] Unfortunately, Clang >does not define __GNUC_GNU_INLINE__ [2]. So a proper feature test >might look like: > >``` >#ifndef __has_attribute >#define __has_attribute(x) 0 >#endif > >#if defined(__GNUC_GNU_INLINE__) || __has_attribute(gnu_inline) >#define __gnu_inline __attribute__(gnu_inline) >#endif > >#define inline inline __attribute__((always_inline, unused)) notrace >__gnu_inline >``` > >Thoughts on this approach? I can send a v5 tomorrow if there's no >major issues. Feedback appreciated, as always. > >[0] https://clang.llvm.org/docs/LanguageExtensions.html#has-attribute >[1] >https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes >[2] https://bugs.llvm.org/show_bug.cgi?id=37784 Please fix clang. It isn't all that hard to fix. However, __GCC_GNU_INLINE__ means you are in GNU mode by default, on gcc's new enough to have multiple misses. The right thing to look for is __GCC_STDC_INLINE__ in which case you need the attribute. By the way, you should check clang against gcc's predefined macros by doing: gcc [options] -x c -Wp,-dM -E /dev/null | sort Options can change the predefined macros substantially, especially the, -std=, arch and -O options. -x c can be replaced with e.g. -x c++, objective-c, assembler-with-cpp etc.
On Tue, Jun 12, 2018 at 11:51 AM H. Peter Anvin <hpa@zytor.com> wrote: > > <caoj.fnst@cn.fujitsu.com>,Greg KH <gregkh@linuxfoundation.org>,jarkko.sakkinen@linux.intel.com,jgross@suse.com,Josh Poimboeuf <jpoimboe@redhat.com>,Matthias Kaehlcke <mka@chromium.org>,thomas.lendacky@amd.com,Thiebaud Weksteen <tweek@google.com>,mjg59@google.com,joe@perches.com > From: hpa@zytor.com > Message-ID: <191E4EBE-4CB2-4C8B-AB61-689A91FFE7A8@zytor.com> > > On June 12, 2018 11:33:14 AM PDT, Nick Desaulniers <ndesaulniers@google.com> wrote: > >On Fri, Jun 8, 2018 at 3:04 AM Sedat Dilek <sedat.dilek@gmail.com> > >wrote: > >> > >> On Fri, Jun 8, 2018 at 9:59 AM, Arnd Bergmann <arnd@arndb.de> wrote: > >> > On Thu, Jun 7, 2018 at 10:49 PM, Nick Desaulniers > >> > <ndesaulniers@google.com> wrote: > >> >> Functions marked extern inline do not emit an externally visible > >> >> function when the gnu89 C standard is used. Some KBUILD Makefiles > >> >> overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as > >without > >> >> an explicit C standard specified, the default is gnu11. Since c99, > >the > >> >> semantics of extern inline have changed such that an externally > >visible > >> >> function is always emitted. This can lead to multiple definition > >errors > >> >> of extern inline functions at link time of compilation units whose > >build > >> >> files have removed an explicit C standard compiler flag for users > >of GCC > >> >> 5.1+ or Clang. > >> >> > >> >> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> > >> >> Suggested-by: H. Peter Anvin <hpa@zytor.com> > >> >> Suggested-by: Joe Perches <joe@perches.com> > >> > > >> > I suspect this will break Geert's gcc-4.1.2, which I think doesn't > >have that > >> > attribute yet (4.1.3 or higher have it according to the > >documentation. > >> > > >> > It wouldn't be hard to work around that if we want to keep that > >version > >> > working, or we could decide that it's time to officially stop > >supporting > >> > that version, but we should probably decide on one or the other. > > > >Heh, so earlier we decided against compiler flags (-std=gnu89 or > >-fgnu89-inline) in preference to function attributes. The function > >attribute is preferable as some of the Makefiles [accidentally?] > >overwrite KBUILD_CFLAGS, which is problematic for gcc 5.1 users as the > >implicit c standard used was changed to gnu11 from gnu89. What's nice > >is that to support gcc 4.1 users, we simply don't need to add any > >attribute, as their implicit c standard is gnu89 which has the > >semantics for extern inline that we want. I have a simple change to > >this patch that can support users of various gcc versions, see below: > > > >> Good point. > >> What is the minimum requirement of GCC version currently? > >> AFAICS x86/asm-goto support requires GCC >= 4.5? > > > >Yes, but that's only for x86, IIUC. It seems the kernel may have > >different minimum required versions of GCC based on arch then? That > >may be ok, but I'm not sure that's easy to keep track of without > >having it explicitly stated somewhere like the docs perhaps? > > > >> Just FYI... > >> ...saw the last days in upstream commits that kbuild/kconfig for > >> 4.18-rc1 offers possibilities to check for cc-version dependencies. > > > >Those will be helpful. If we want to pursue compiler flags, which get > >set some Makefiles, then yes. But I think a simpler change to my > >patch would be as below. > > > >It seems gcc did not get __has_attribute [0] until 5.1, but will > >define __GNUC_GNU_INLINE__ if supported. [1] Unfortunately, Clang > >does not define __GNUC_GNU_INLINE__ [2]. So a proper feature test > >might look like: > > > >``` > >#ifndef __has_attribute > >#define __has_attribute(x) 0 > >#endif > > > >#if defined(__GNUC_GNU_INLINE__) || __has_attribute(gnu_inline) > >#define __gnu_inline __attribute__(gnu_inline) > >#endif > > > >#define inline inline __attribute__((always_inline, unused)) notrace > >__gnu_inline > >``` > > > >Thoughts on this approach? I can send a v5 tomorrow if there's no > >major issues. Feedback appreciated, as always. > > > >[0] https://clang.llvm.org/docs/LanguageExtensions.html#has-attribute > >[1] > >https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes > >[2] https://bugs.llvm.org/show_bug.cgi?id=37784 > > Please fix clang. It isn't all that hard to fix. > > However, __GCC_GNU_INLINE__ means you are in GNU mode by default, on gcc's new enough to have multiple misses. > > The right thing to look for is __GCC_STDC_INLINE__ in which case you need the attribute. Oh, by [0] __GCC_STDC_INLINE__ is indeed actually the correct symbol to check for. Clang does support that, so nothing to fix there. > By the way, you should check clang against gcc's predefined macros by doing: > > gcc [options] -x c -Wp,-dM -E /dev/null | sort > > Options can change the predefined macros substantially, especially the, -std=, arch and -O options. -x c can be replaced with e.g. -x c++, objective-c, assembler-with-cpp etc. Neat, I'll have to bookmark that incantation. I can s/gcc/clang/ to get a similar list (which is how I know it supports __GCC_STDC_INLINE__). Patch now becomes something like: #ifdef __GNUC_GNU_INLINE__ #define __gnu_inline __attribute__((gnu_inline)) #else #define __gnu_inline #endif #define inline inline __attribute__((always_inline, unused)) notrace __gnu_inline ... Issues with that approach? [0] https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
On 06/12/18 13:19, Nick Desaulniers wrote: > > Oh, by [0] __GCC_STDC_INLINE__ is indeed actually the correct symbol > to check for. Clang does support that, so nothing to fix there. > >> By the way, you should check clang against gcc's predefined macros by doing: >> >> gcc [options] -x c -Wp,-dM -E /dev/null | sort >> >> Options can change the predefined macros substantially, especially the, -std=, arch and -O options. -x c can be replaced with e.g. -x c++, objective-c, assembler-with-cpp etc. > > Neat, I'll have to bookmark that incantation. I can s/gcc/clang/ to > get a similar list (which is how I know it supports > __GCC_STDC_INLINE__).> I bet that if you add -fgnu89-inlines then it *does* define __GNUC_GNU_INLINE__. > > Patch now becomes something like: > > #ifdef __GNUC_GNU_INLINE__ > #define __gnu_inline __attribute__((gnu_inline)) > #else > #define __gnu_inline > #endif > > #define inline inline __attribute__((always_inline, unused)) notrace > __gnu_inline > ... > > Issues with that approach? > s/__GNUC_GNU_INLINE__/__GNUC_STDC_INLINE__/ -hpa -- 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 Tue, Jun 12, 2018 at 2:31 PM H. Peter Anvin <hpa@zytor.com> wrote: > > On 06/12/18 13:19, Nick Desaulniers wrote: > > > > Oh, by [0] __GCC_STDC_INLINE__ is indeed actually the correct symbol > > to check for. Clang does support that, so nothing to fix there. > > > >> By the way, you should check clang against gcc's predefined macros by doing: > >> > >> gcc [options] -x c -Wp,-dM -E /dev/null | sort > >> > >> Options can change the predefined macros substantially, especially the, -std=, arch and -O options. -x c can be replaced with e.g. -x c++, objective-c, assembler-with-cpp etc. > > > > Neat, I'll have to bookmark that incantation. I can s/gcc/clang/ to > > get a similar list (which is how I know it supports > > __GCC_STDC_INLINE__).> > > I bet that if you add -fgnu89-inlines then it *does* define > __GNUC_GNU_INLINE__. Indeed! I see what you mean about [options] changing the predefined symbol list. > > Patch now becomes something like: > > > > #ifdef __GNUC_GNU_INLINE__ > > #define __gnu_inline __attribute__((gnu_inline)) > > #else > > #define __gnu_inline > > #endif > > > > #define inline inline __attribute__((always_inline, unused)) notrace > > __gnu_inline > > ... > > > > Issues with that approach? > > > > s/__GNUC_GNU_INLINE__/__GNUC_STDC_INLINE__/ Oops, sorry, yes good catch.
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h index b4bf73f5e38f..0c79c588e572 100644 --- a/include/linux/compiler-gcc.h +++ b/include/linux/compiler-gcc.h @@ -72,19 +72,22 @@ * -Wunused-function. This turns out to avoid the need for complex #ifdef * directives. Suppress the warning in clang as well by using "unused" * function attribute, which is redundant but not harmful for gcc. + * Prefer gnu_inline, so that extern inline functions do not emit an + * externally visible function. This makes extern inline behave as per gnu89 + * semantics rather than c99. This prevents multiple symbol definition errors + * of extern inline functions at link time. + * A lot of inline functions can cause havoc with function tracing. */ #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \ !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4) -#define inline inline __attribute__((always_inline,unused)) notrace -#define __inline__ __inline__ __attribute__((always_inline,unused)) notrace -#define __inline __inline __attribute__((always_inline,unused)) notrace +#define inline \ + inline __attribute__((always_inline, unused, gnu_inline)) notrace #else -/* A lot of inline functions can cause havoc with function tracing */ -#define inline inline __attribute__((unused)) notrace -#define __inline__ __inline__ __attribute__((unused)) notrace -#define __inline __inline __attribute__((unused)) notrace +#define inline inline __attribute__((unused, gnu_inline)) notrace #endif +#define __inline__ inline +#define __inline inline #define __always_inline inline __attribute__((always_inline)) #define noinline __attribute__((noinline))
Functions marked extern inline do not emit an externally visible function when the gnu89 C standard is used. Some KBUILD Makefiles overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without an explicit C standard specified, the default is gnu11. Since c99, the semantics of extern inline have changed such that an externally visible function is always emitted. This can lead to multiple definition errors of extern inline functions at link time of compilation units whose build files have removed an explicit C standard compiler flag for users of GCC 5.1+ or Clang. Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Suggested-by: H. Peter Anvin <hpa@zytor.com> Suggested-by: Joe Perches <joe@perches.com> --- include/linux/compiler-gcc.h | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-)