From c30724e9a061135f8c7b925c0fcdf742510a3bc5 Mon Sep 17 00:00:00 2001 From: Rasmus Villemoes Date: Fri, 13 Sep 2019 00:19:24 +0200 Subject: 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 --- include/linux/compiler_types.h | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) (limited to 'include/linux/compiler_types.h') diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h index 599c27b56c29..ee49be6d6088 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 -- cgit