Re: [PATCH 2/7] Compiler Attributes: use the no-underscores syntax

[Nick Desaulniers <ndesaulniers@google.com>]

On Fri, Aug 31, 2018 at 10:05 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> The attribute syntax optionally allows to surround attribute names
> with "__" in order to avoid collisions with macros of the same name
> (see https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html).
>
> This homogenizes all attributes to use the syntax without underscores.
>
> Cc: Eli Friedman <efriedma@codeaurora.org>
> Cc: Christopher Li <sparse@chrisli.org>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> Cc: Joe Perches <joe@perches.com>
> Cc: Dominique Martinet <asmadeus@codewreck.org>
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
> ---
>  include/linux/compiler-clang.h | 2 +-
>  include/linux/compiler-gcc.h   | 4 ++--
>  include/linux/compiler.h       | 4 ++--
>  include/linux/compiler_types.h | 8 ++++----
>  4 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> index b1ce500fe8b3..efda74f4eeba 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -43,4 +43,4 @@
>  #define barrier() __asm__ __volatile__("" : : : "memory")
>  #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
>  #define __assume_aligned(a, ...)       \
> -       __attribute__((__assume_aligned__(a, ## __VA_ARGS__)))
> +       __attribute__((assume_aligned(a, ## __VA_ARGS__)))
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 0a2d06677d83..dbfbecf703f8 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -132,7 +132,7 @@
>         } while (0)
>
>  /* Mark a function definition as prohibited from being cloned. */
> -#define __noclone      __attribute__((__noclone__, __optimize__("no-tracer")))
> +#define __noclone      __attribute__((noclone, optimize("no-tracer")))
>
>  #if defined(RANDSTRUCT_PLUGIN) && !defined(__CHECKER__)
>  #define __randomize_layout __attribute__((randomize_layout))
> @@ -165,7 +165,7 @@
>   * compiler should see some alignment anyway, when the return value is
>   * massaged by 'flags = ptr & 3; ptr &= ~3;').
>   */
> -#define __assume_aligned(a, ...) __attribute__((__assume_aligned__(a, ## __VA_ARGS__)))
> +#define __assume_aligned(a, ...) __attribute__((assume_aligned(a, ## __VA_ARGS__)))
>  #endif
>
>  /*
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 7c0157d50964..e0e55eb3f242 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -23,7 +23,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
>  #define __branch_check__(x, expect, is_constant) ({                    \
>                         long ______r;                                   \
>                         static struct ftrace_likely_data                \
> -                               __attribute__((__aligned__(4)))         \
> +                               __attribute__((aligned(4)))             \

Can this be __aligned(4)? As in make use of the newly feature detected
attributes?

>                                 __attribute__((section("_ftrace_annotated_branch"))) \

Sorry to ask for cleanups on code you didn't touch, but since you're
here, can you make this __section("_ftrace_annotated_branch")?

>                                 ______f = {                             \
>                                 .data.func = __func__,                  \
> @@ -59,7 +59,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
>         ({                                                              \
>                 int ______r;                                            \
>                 static struct ftrace_branch_data                        \
> -                       __attribute__((__aligned__(4)))                 \
> +                       __attribute__((aligned(4)))                     \
>                         __attribute__((section("_ftrace_branch")))      \

Ditto.

>                         ______f = {                                     \
>                                 .func = __func__,                       \
> diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
> index b6534292ea33..7cd958360ead 100644
> --- a/include/linux/compiler_types.h
> +++ b/include/linux/compiler_types.h
> @@ -159,7 +159,7 @@ struct ftrace_likely_data {
>          sizeof(t) == sizeof(int) || sizeof(t) == sizeof(long))
>
>  #ifndef __attribute_const__
> -#define __attribute_const__    __attribute__((__const__))
> +#define __attribute_const__    __attribute__((const))
>  #endif
>
>  #ifndef __noclone
> @@ -203,14 +203,14 @@ struct ftrace_likely_data {
>  #define __maybe_unused         __attribute__((unused))
>  #define __always_unused                __attribute__((unused))
>  #define __mode(x)              __attribute__((mode(x)))
> -#define __malloc               __attribute__((__malloc__))
> -#define __used                 __attribute__((__used__))
> +#define __malloc               __attribute__((malloc))
> +#define __used                 __attribute__((used))
>  #define __noreturn             __attribute__((noreturn))
>  #define __packed               __attribute__((packed))
>  #define __weak                 __attribute__((weak))
>  #define __alias(symbol)                __attribute__((alias(#symbol)))
>  #define __cold                 __attribute__((cold))
> -#define __section(S)           __attribute__((__section__(#S)))
> +#define __section(S)           __attribute__((section(#S)))
>
>
>  #ifdef CONFIG_ENABLE_MUST_CHECK
> --
> 2.17.1
>

With the above changes requested (or follow up patch added to the series):
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>

Also,
Series looks great, trying to provide reviews one by one, just very
busy today (and Monday off).

-- 
Thanks,
~Nick Desaulniers