redonkable
/
alistair23-linux
1
0
Fork 0
Code Releases Activity

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>
alistair/sunxi64-5.4-dsi
Rasmus Villemoes 2019-09-13 00:19:24 +02:00 committed by Miguel Ojeda
parent 4bd92428e7
commit c30724e9a0
1 changed files with 10 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
include/linux/compiler_types.h
View File

@ -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