Commit c30724e9 authored Sep 13, 2019 by Rasmus Villemoes Committed by Miguel Ojeda Sep 15, 2019

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 <linux@rasmusvillemoes.dk>
[Fix trivial typo in message]
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>

parent 4bd92428

include/linux/compiler_types.h

+10 −1

Original line number	Diff line number	Diff line
		@@ -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