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>
This commit is contained in:
parent
4bd92428e7
commit
c30724e9a0
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user