linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Paul Burton <paul.burton@mips.com>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Linux-MIPS <linux-mips@linux-mips.org>,
	Ingo Molnar <mingo@kernel.org>, Matthew Wilcox <matthew@wil.cx>,
	Thomas Gleixner <tglx@linutronix.de>,
	Douglas Anderson <dianders@chromium.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Matthias Kaehlcke <mka@chromium.org>,
	He Zhe <zhe.he@windriver.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Michal Marek <michal.lkml@markovi.net>,
	Khem Raj <raj.khem@gmail.com>,
	Christophe Leroy <christophe.leroy@c-s.fr>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Stafford Horne <shorne@gmail.com>,
	Gideon Israel Dsouza <gidisrael@gmail.com>,
	Kees Cook <keescook@chromium.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Paul Mackerras <paulus@samba.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 1/3] kbuild: add macro for controlling warnings to linux/compiler.h
Date: Tue, 19 Jun 2018 12:02:25 -0700	[thread overview]
Message-ID: <20180619190225.7eguhiw3ixaiwpgl@pburton-laptop> (raw)
In-Reply-To: <CAK7LNASvCha27kU4ipn23uOpNuxkzJrNzWBwYcxN4n=3xtv8SA@mail.gmail.com>

Hi Masahiro,

On Wed, Jun 20, 2018 at 02:34:35AM +0900, Masahiro Yamada wrote:
> 2018-06-16 9:53 GMT+09:00 Paul Burton <paul.burton@mips.com>:
> > diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> > index f1a7492a5cc8..aba64a2912d8 100644
> > --- a/include/linux/compiler-gcc.h
> > +++ b/include/linux/compiler-gcc.h
> > @@ -347,3 +347,69 @@
> >  #if GCC_VERSION >= 50100
> >  #define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
> >  #endif
> > +
> > +/*
> > + * turn individual warnings and errors on and off locally, depending
> > + * on version.
> > + */
> > +#define __diag_GCC(version, s) __diag_GCC_ ## version(s)
> > +
> > +#if GCC_VERSION >= 40600
> > +#define __diag_str1(s) #s
> > +#define __diag_str(s) __diag_str1(s)
> > +#define __diag(s) _Pragma(__diag_str(GCC diagnostic s))
> > +
> > +/* compilers before gcc-4.6 do not understand "#pragma GCC diagnostic push" */
> > +#define __diag_GCC_4_6(s) __diag(s)
> > +#else
> > +#define __diag(s)
> > +#define __diag_GCC_4_6(s)
> > +#endif
> > +
> > +#if GCC_VERSION >= 40700
> > +#define __diag_GCC_4_7(s) __diag(s)
> > +#else
> > +#define __diag_GCC_4_7(s)
> > +#endif
> > +
> > +#if GCC_VERSION >= 40800
> > +#define __diag_GCC_4_8(s) __diag(s)
> > +#else
> > +#define __diag_GCC_4_8(s)
> > +#endif
> > +
> > +#if GCC_VERSION >= 40900
> > +#define __diag_GCC_4_9(s) __diag(s)
> > +#else
> > +#define __diag_GCC_4_9(s)
> > +#endif
> > +
> > +#if GCC_VERSION >= 50000
> > +#define __diag_GCC_5(s) __diag(s)
> > +#else
> > +#define __diag_GCC_5(s)
> > +#endif
> > +
> > +#if GCC_VERSION >= 60000
> > +#define __diag_GCC_6(s) __diag(s)
> > +#else
> > +#define __diag_GCC_6(s)
> > +#endif
> > +
> > +#if GCC_VERSION >= 70000
> > +#define __diag_GCC_7(s) __diag(s)
> > +#else
> > +#define __diag_GCC_7(s)
> > +#endif
> > +
> > +#if GCC_VERSION >= 80000
> > +#define __diag_GCC_8(s) __diag(s)
> > +#else
> > +#define __diag_GCC_8(s)
> > +#endif
> > +
> > +#if GCC_VERSION >= 90000
> > +#define __diag_GCC_9(s) __diag(s)
> > +#else
> > +#define __diag_GCC_9(s)
> > +#endif
> 
> 
> Hmm, we would have to add this for every release.

Well, strictly speaking only ones that we need to modify diags for - ie.
in this series we could get away with only adding the GCC 8 macro if we
wanted.

> > diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
> > index 6b79a9bba9a7..313a2ad884e0 100644
> > --- a/include/linux/compiler_types.h
> > +++ b/include/linux/compiler_types.h
> > @@ -271,4 +271,22 @@ struct ftrace_likely_data {
> >  # define __native_word(t) (sizeof(t) == sizeof(char) || sizeof(t) == sizeof(short) || sizeof(t) == sizeof(int) || sizeof(t) == sizeof(long))
> >  #endif
> >
> > +#ifndef __diag
> > +#define __diag(string)
> > +#endif
> > +
> > +#ifndef __diag_GCC
> > +#define __diag_GCC(string)
> > +#endif
> 
> __diag_GCC() takes two arguments,
> so it should be:
> 
> #ifndef __diag_GCC
> #define __diag_GCC(version, s)
> #endif
> 
> 
> Otherwise, this would cause warning like this:
> 
> 
> arch/arm64/kernel/sys.c:40:1: error: macro "__diag_GCC" passed 2
> arguments, but takes just 1
>  SYSCALL_DEFINE1(arm64_personality, unsigned int, personality)
>  ^~~~~~~~~~

Yes, good catch.

> > +#define __diag_push()  __diag(push)
> > +#define __diag_pop()   __diag(pop)
> > +
> > +#define __diag_ignore(compiler, version, option, comment) \
> > +       __diag_ ## compiler(version, ignored option)
> > +#define __diag_warn(compiler, version, option, comment) \
> > +       __diag_ ## compiler(version, warning option)
> > +#define __diag_error(compiler, version, option, comment) \
> > +       __diag_ ## compiler(version, error   option)
> > +
> 
> To me, it looks like this is putting GCC/Clang specific things
> in the common file, <linux/compiler_types.h> .
> 
> All compilers must use "ignored", "warning", "error",
> not allowed to use "ignore".

We could move that to linux/compiler-gcc.h pretty easily.

> I also wonder if we could avoid proliferating __diag_GCC_*.

My thought is that it's unlikely we'll ever support enough different
compilers for it to become problematic to list the ones we modify
warnings for in linux/compiler_types.h.

> I attached a bit different implementation below.
> 
> I used -Wno-pragmas to avoid unknown option warnings.

That doesn't seem very clean to me because it will hide typos or other
mistakes. One advantage of Arnd's patch is that by specifying the
compiler & version we only attempt to use pragmas that are appropriate
so we don't need to ignore unknown ones.

> Usage is
> 
>        __diag_push();
>        __diag_ignore(-Wattribute-alias,
>                      "Type aliasing is used to sanitize syscall arguments");
>               ...
>        __diag_pop();
> 
> Comments, ideas are appreciated.

By removing the compiler & version arguments you're enforcing that if we
ignore a warning for one compiler we must ignore it for all, regardless
of whether it's problematic. This essentially presumes that warnings
with the same name will behave the same across compilers, which feels
worse to me than having users of this explicitly state which compilers
need the pragmas.

Thanks,
    Paul

  reply	other threads:[~2018-06-19 19:03 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-16  0:53 [PATCH 0/3] Resolve -Wattribute-alias warnings from SYSCALL_DEFINEx() Paul Burton
2018-06-16  0:53 ` [PATCH 1/3] kbuild: add macro for controlling warnings to linux/compiler.h Paul Burton
2018-06-18  7:01   ` Christophe LEROY
2018-06-19 17:34   ` Masahiro Yamada
2018-06-19 19:02     ` Paul Burton [this message]
2018-06-19 20:14       ` [PATCH v2 0/3] Resolve -Wattribute-alias warnings from SYSCALL_DEFINEx() Paul Burton
2018-06-19 20:14         ` [PATCH v2 1/3] kbuild: add macro for controlling warnings to linux/compiler.h Paul Burton
2018-06-20 23:17           ` Masahiro Yamada
2018-06-19 20:14         ` [PATCH v2 2/3] disable -Wattribute-alias warning for SYSCALL_DEFINEx() Paul Burton
2018-06-19 20:14         ` [PATCH v2 3/3] powerpc: Remove -Wattribute-alias pragmas Paul Burton
2018-06-20 13:40           ` Christophe LEROY
2018-06-23  8:40         ` [PATCH v2 0/3] Resolve -Wattribute-alias warnings from SYSCALL_DEFINEx() Masahiro Yamada
2018-06-20 23:21       ` [PATCH 1/3] kbuild: add macro for controlling warnings to linux/compiler.h Masahiro Yamada
2018-06-21  0:02         ` Paul Burton
2018-06-16  0:53 ` [PATCH 2/3] disable -Wattribute-alias warning for SYSCALL_DEFINEx() Paul Burton
2018-06-18  7:01   ` Christophe LEROY
2018-06-16  0:53 ` [PATCH 3/3] Revert "powerpc: fix build failure by disabling attribute-alias warning in pci_32" Paul Burton
2018-06-18  7:01   ` Christophe LEROY
2018-06-19 13:01   ` Michael Ellerman
2018-06-17  1:11 ` [PATCH 0/3] Resolve -Wattribute-alias warnings from SYSCALL_DEFINEx() Stafford Horne
2018-06-18  7:00 ` Christophe LEROY
2018-06-18 13:05 ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180619190225.7eguhiw3ixaiwpgl@pburton-laptop \
    --to=paul.burton@mips.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=christophe.leroy@c-s.fr \
    --cc=dianders@chromium.org \
    --cc=gidisrael@gmail.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jpoimboe@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=matthew@wil.cx \
    --cc=mchehab@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=mingo@kernel.org \
    --cc=mka@chromium.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=raj.khem@gmail.com \
    --cc=shorne@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yamada.masahiro@socionext.com \
    --cc=zhe.he@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).