diff options
| author | Rasmus Villemoes <linux@rasmusvillemoes.dk> | 2019-09-13 00:19:24 +0200 |
|---|---|---|
| committer | Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> | 2019-09-15 20:14:15 +0200 |
| commit | c30724e9a061135f8c7b925c0fcdf742510a3bc5 (patch) | |
| tree | 6cde7233c164d422d1292781ef6112998313a279 /include/linux/compiler_types.h | |
| parent | 4bd92428e717fc6bc29ffa4fdb38b68395b96684 (diff) | |
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>
Diffstat (limited to 'include/linux/compiler_types.h')
| -rw-r--r-- | include/linux/compiler_types.h | 11 |
1 files changed, 10 insertions, 1 deletions
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 |