From: Pedro Alves <palves@redhat.com>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: "Jose E. Marchesi" <jose.marchesi@oracle.com>,
Yao Qi <qiyaoltc@gmail.com>,
"gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: C++ conversion status update
Date: Wed, 16 Dec 2015 22:10:00 -0000 [thread overview]
Message-ID: <5671E16C.1080907@redhat.com> (raw)
In-Reply-To: <CAFXXi0k5oe3nvQRATv1T-fh0+m_jnWBPZHLFzBK6PzqcSzJedQ@mail.gmail.com>
On 12/16/2015 08:29 PM, Simon Marchi wrote:
> On 16 December 2015 at 15:15, Pedro Alves <palves@redhat.com> wrote:
>> Simon, do you see this one?
>
> Yes, but it doesn't seem to make the compilation fail on its own
> (despite stating it's an error). I only see it when the build fails
> because of another error. I figured that that flag was introduced gcc
> version, and that it doesn't hurt if it's not recognized.
Ah, yes, that's it. We have code in configure.ac that tries to
detect whether the compiler supports each warning and suppress it
it no, but it's getting fooled by:
"When an unrecognized warning option is requested (e.g., -Wunknown-warning), GCC emits a
diagnostic stating that the option is not recognized. However, if the -Wno- form is used, the
behavior is slightly different: no diagnostic is produced for -Wno-unknown-warning unless other
diagnostics are being produced. This allows the use of new -Wno- options with old
compilers, but if something goes wrong, the compiler warns that an unrecognized
option is present."
That's from https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html.
I think we can handle this by making that warning-support test code
check whether -Wfoo works when we actually want -Wno-foo.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2015-12-16 22:10 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-24 13:07 Pedro Alves
2015-12-14 14:40 ` Yao Qi
2015-12-14 19:09 ` Pedro Alves
2015-12-15 11:39 ` Jose E. Marchesi
2015-12-15 20:03 ` Simon Marchi
2015-12-16 0:19 ` Pedro Alves
2015-12-16 0:21 ` Pedro Alves
2015-12-16 1:19 ` Simon Marchi
2015-12-16 20:11 ` Pedro Alves
2015-12-16 20:15 ` Pedro Alves
2015-12-16 20:30 ` Simon Marchi
2015-12-16 22:10 ` Pedro Alves [this message]
2015-12-16 22:59 ` Pedro Alves
2016-01-19 19:00 ` John Baldwin
2016-01-20 11:10 ` Pedro Alves
2016-01-20 23:33 ` John Baldwin
2016-01-21 11:38 ` Pedro Alves
2016-04-16 0:21 ` Pedro Alves
2016-04-18 16:51 ` Pedro Alves
2016-04-19 19:26 ` John Baldwin
2016-04-19 20:36 ` Pedro Alves
2016-04-19 21:40 ` John Baldwin
2016-04-19 22:20 ` Pedro Alves
2016-04-13 0:25 ` Pedro Alves
2016-04-13 11:07 ` Yao Qi
2016-04-13 14:13 ` Pedro Alves
2016-04-13 14:31 ` Sergio Durigan Junior
2016-04-13 12:41 ` Joel Brobecker
2016-04-13 14:04 ` Pedro Alves
2016-04-13 14:16 ` Joel Brobecker
2016-04-13 14:27 ` Luis Machado
2016-04-13 14:35 ` Marc Khouzam
2016-04-13 14:59 ` Joel Brobecker
2016-04-13 14:40 ` Pedro Alves
2016-04-18 17:29 ` Pedro Alves
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=5671E16C.1080907@redhat.com \
--to=palves@redhat.com \
--cc=gdb@sourceware.org \
--cc=jose.marchesi@oracle.com \
--cc=qiyaoltc@gmail.com \
--cc=simon.marchi@polymtl.ca \
/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