From: Pedro Alves <palves@redhat.com>
To: Simon Marchi <simon.marchi@ericsson.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH 2/3] vec: Silence -Wunused-function warnings on clang
Date: Mon, 26 Jun 2017 09:28:00 -0000 [thread overview]
Message-ID: <f3aabf75-572b-8d7c-5d78-694c7b099c44@redhat.com> (raw)
In-Reply-To: <1498412703-24303-3-git-send-email-simon.marchi@ericsson.com>
On 06/25/2017 06:45 PM, Simon Marchi wrote:
> clang has a too aggressive (or broken, depends on how you want to see
> it) -Wunused-function warning,
There's no way to avoid the warning in this use case, so I can't see
how to call it anything but the latter.
> which is triggered by the functions
> defined by DEF_VEC_* but not used in the current source file. Normally,
> it won't warn about unused static inline functions defined in header
> files, because it's expected that a source file won't use all functions
> defined in a header file it includes. However, the DEF_VEC_* macros
> define those functions in source files, which leads clang to think that
> we should remove those functions. It is therefore missing a check to
> see whether those functions are resulting from macro expansion. A bug
> already exists for that:
>
> https://bugs.llvm.org//show_bug.cgi?id=22712
>
> It's quite easy to silence this warning in a localized way, that is in
> the DEF_VEC_* macros.
>
> gdb/ChangeLog:
>
> * common/diagnostics.h (DIAGNOSTIC_IGNORE_UNUSED_FUNCTION): New
> macro.
> * common/vec.h: Include diagnostics.h.
> (DEF_VEC_I, DEF_VEC_P, DEF_VEC_O): Ignore -Wunused-function
> warning.
> ---
> gdb/common/diagnostics.h | 3 +++
> gdb/common/vec.h | 11 +++++++++++
> 2 files changed, 14 insertions(+)
>
> diff --git a/gdb/common/diagnostics.h b/gdb/common/diagnostics.h
> index 35bacf2..ee824a3 100644
> --- a/gdb/common/diagnostics.h
> +++ b/gdb/common/diagnostics.h
> @@ -35,9 +35,12 @@
> # define DIAGNOSTIC_IGNORE_SELF_MOVE DIAGNOSTIC_IGNORE ("-Wself-move")
> # define DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER \
> DIAGNOSTIC_IGNORE ("-Wdeprecated-register")
> +# define DIAGNOSTIC_IGNORE_UNUSED_FUNCTION \
> + DIAGNOSTIC_IGNORE ("-Wunused-function")
GCC also understands this warning. So I think we should define
the ignore macro for GCC too.
Now that raises the question of whether you want to suppress the
warning in vec.h for GCC too. But that's actually the point
that made me come here to comment:
Imagine that we'll want to suppress -Wunused-function with GCC
in some other source file, for some reason. At that point we'll
naturally want to adjust diagnostics.h to define
# define DIAGNOSTIC_IGNORE_UNUSED_FUNCTION \
DIAGNOSTIC_IGNORE ("-Wunused-function")
for GCC too instead of leaving DIAGNOSTIC_IGNORE_UNUSED_FUNCTION empty
for GCC. But, that will make the existing (at that time) users
of DIAGNOSTIC_IGNORE_UNUSED_FUNCTION start suppressing the warning
on GCC too, and we may or not want that.
This, to me indicates that:
#1 - The common/diagnostics.h macros define the non-empty "ignore"
macro on all compilers that understand it. Then vec.h does:
DIAGNOSTIC_PUSH
#ifdef __clang__
DIAGNOSTIC_IGNORE_UNUSED_FUNCTION
#endif
#2 - We name the macro something else more targeted for this
specific use case, and define it to empty for GCC, and to
-Wunused-function on clang.
#2.1 - If put on common/diagnostics.h, name it something
generic, like:
/* Suppress -Wunused-function for functions defined in source files as
result of expanding macros (that define the functions) defined
in headers. */
#ifdef __lang
# define DIAGNOSTIC_IGNORE_UNUSED_FUNCTION_HEADER_MACRO_EXPANSION \
DIAGNOSTIC_IGNORE_UNUSED_FUNCTION
#else
# define DIAGNOSTIC_IGNORE_UNUSED_FUNCTION_HEADER_MACRO_EXPANSION
#endif
#2.2 - Otherwise, define DIAGNOSTIC_IGNORE_UNUSED_FUNCTION
for for GCC and clang, and put something like this on
top of vec.h:
/* Comment describing issue and pointing to clang bug report. */
#ifdef __clang__
#define DIAGNOSTIC_IGNORE_UNUSED_VEC_FUNCTION \
DIAGNOSTIC_IGNORE_UNUSED_FUNCTION
#else
#define DIAGNOSTIC_IGNORE_UNUSED_VEC_FUNCTION
#endif
And use that instead of DIAGNOSTIC_IGNORE_FUNCTION.
I think I prefer #2.2, then #2.1, then #1.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2017-06-26 9:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-25 17:45 [PATCH 0/3] Third series towards a warning-less clang build Simon Marchi
2017-06-25 17:45 ` [PATCH 1/3] ada-lex: Ignore warnings about register keyword Simon Marchi
2017-06-26 13:13 ` Pedro Alves
2017-06-26 13:39 ` Simon Marchi
2017-06-26 14:54 ` [pushed] " Simon Marchi
2017-06-25 17:45 ` [PATCH 2/3] vec: Silence -Wunused-function warnings on clang Simon Marchi
2017-06-26 9:28 ` Pedro Alves [this message]
2017-06-26 12:28 ` Simon Marchi
2017-06-26 12:47 ` Pedro Alves
2017-06-26 12:52 ` Simon Marchi
[not found] ` <1498481156-10705-1-git-send-email-simon.marchi@ericsson.com>
2017-06-26 13:03 ` [PATCH 2/3 v2] " Pedro Alves
2017-06-25 17:45 ` [PATCH 3/3] record-full: Remove unused function netorder16 Simon Marchi
2017-06-26 10:43 ` Yao Qi
2017-06-26 14:54 ` Simon Marchi
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=f3aabf75-572b-8d7c-5d78-694c7b099c44@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@ericsson.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