From: Rasmus Villemoes Date: Thu, 12 Sep 2019 22:19:24 +0000 (+0200) Subject: compiler_types.h: don't #define __inline X-Git-Url: http://git.maquefel.me/?a=commitdiff_plain;h=c30724e9a061135f8c7b925c0fcdf742510a3bc5;p=linux.git compiler_types.h: don't #define __inline The spellings __inline and __inline__ should be reserved for uses where one really wants to refer to the inline keyword, regardless of whether or not the spelling "inline" has been #defined to something else. Due to use of __inline__ in uapi headers, we can't easily get rid of the definition of __inline__. However, almost all users of __inline have been converted to inline, so we can get rid of that #define. The exception is include/acpi/platform/acintel.h. However, that header is only included when using the intel compiler (does anybody actually build the kernel with that?), and the ACPI_INLINE macro is only used in the definition of utterly trivial stub functions, where I doubt a small change of semantics (lack of __gnu_inline) changes anything. Signed-off-by: Rasmus Villemoes [Fix trivial typo in message] Signed-off-by: Miguel Ojeda --- diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h index 599c27b56c29a..ee49be6d60882 100644 --- a/include/linux/compiler_types.h +++ b/include/linux/compiler_types.h @@ -150,8 +150,17 @@ struct ftrace_likely_data { __maybe_unused notrace #endif +/* + * gcc provides both __inline__ and __inline as alternate spellings of + * the inline keyword, though the latter is undocumented. New kernel + * code should only use the inline spelling, but some existing code + * uses __inline__. Since we #define inline above, to ensure + * __inline__ has the same semantics, we need this #define. + * + * However, the spelling __inline is strictly reserved for referring + * to the bare keyword. + */ #define __inline__ inline -#define __inline inline /* * Rather then using noinline to prevent stack consumption, use