From: Yao Qi <qiyaoltc@gmail.com>
To: Simon Marchi <simon.marchi@ericsson.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
Simon Marchi <simon.marchi@polymtl.ca>,
<gdb-patches@sourceware.org>,
palves@redhat.com
Subject: Re: [PATCH 0/5] Remove a few hurdles of compiling with clang
Date: Tue, 13 Jun 2017 15:22:00 -0000 [thread overview]
Message-ID: <86o9trdib1.fsf@gmail.com> (raw)
In-Reply-To: <b69c7255-122b-cc25-005c-f16f34cffc4a@ericsson.com> (Simon Marchi's message of "Tue, 13 Jun 2017 12:23:27 +0200")
Simon Marchi <simon.marchi@ericsson.com> writes:
> If somebody is willing to do the work and that it doesn't degrade the code quality,
> we should have no problem accepting it. So if it's a "side-step" that allows both
> compilers to be happy, that's ok. As a patch submitter, if you use primarily GCC,
> you are not required to test your patches with Clang, but if you use primarily Clang,
> you must test your patch with GCC (a version that's easily accessible for you).
>
> Does that sound like a good rule?
Yes, it is equivalent to "it is not acceptable to build GDB with
compiler X but break the build with GCC" in my last email.
I add some comments from Simon and Pedro. Eli, is it good to you?
In general, it is good to keep GDB built by different popular compilers,
so people are easy to build GDB and different warnings from different
compilers will catch more bugs in GDB. On the other hand, GCC is still
the primary compiler to build GDB, and support of other compilers in
building GDB should not undermine the case that GDB is built by GCC nor
degrade the code quality. For example, it is not acceptable to build
GDB with compiler X but break the build with GCC. We still must fix
the GDB build failure with GCC, as what we did in the past, and we
welcome the contributions to fix the GDB build with other compilers.
Ideally, every bug that other compilers find in the GDB source code
that GCC didn't warn about should be considered as a GCC bug, and we
should make sure that it's reported on the GCC tracker.
I also looked for the place to add this policy. Looks the most relevant
page is https://sourceware.org/gdb/wiki/Internals%20Compiler-Warnings
--
Yao (齐尧)
next prev parent reply other threads:[~2017-06-13 15:22 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-10 19:58 Simon Marchi
2017-06-10 19:58 ` [PATCH 5/5] Add ATTRIBUTE_PRINTF to trace_start_error Simon Marchi
2017-06-14 19:49 ` Sergio Durigan Junior
2017-06-10 19:58 ` [PATCH 4/5] linux-low: Remove usage of "register" keyword Simon Marchi
2017-06-10 19:58 ` [PATCH 3/5] gdb: Add -Wno-mismatched-tags Simon Marchi
2017-06-10 19:58 ` [PATCH 2/5] gdb: Use -Werror when checking for (un)supported warning flags Simon Marchi
2017-06-10 19:58 ` [PATCH 1/5] gdb: Pass -x c++ to the compiler Simon Marchi
2017-06-11 2:36 ` [PATCH 0/5] Remove a few hurdles of compiling with clang Eli Zaretskii
2017-06-12 7:56 ` Yao Qi
2017-06-12 14:36 ` Eli Zaretskii
2017-06-12 15:54 ` Simon Marchi
2017-06-12 16:23 ` Andrew Pinski
2017-06-12 16:35 ` Pedro Alves
2017-06-12 16:37 ` Andrew Pinski
2017-06-12 16:45 ` Pedro Alves
2017-06-12 16:55 ` Pedro Alves
2017-06-12 16:44 ` Simon Marchi
2017-06-12 16:55 ` Andrew Pinski
2017-06-12 17:00 ` Simon Marchi
2017-06-12 16:44 ` Eli Zaretskii
2017-06-13 9:14 ` Yao Qi
2017-06-13 10:23 ` Simon Marchi
2017-06-13 11:06 ` Pedro Alves
2017-06-13 11:08 ` Simon Marchi
2017-06-13 14:38 ` Eli Zaretskii
2017-06-13 17:07 ` Simon Marchi
2017-06-13 19:23 ` Eli Zaretskii
2017-06-13 20:17 ` Simon Marchi
2017-06-14 2:29 ` Eli Zaretskii
2017-06-14 10:45 ` Pedro Alves
2017-06-16 16:12 ` John Baldwin
2017-06-13 15:22 ` Yao Qi [this message]
2017-06-13 15:44 ` Eli Zaretskii
2017-06-14 9:07 ` Yao Qi
2017-06-19 8:07 ` Yao Qi
2017-06-13 10:44 ` Pedro Alves
2017-06-13 15:09 ` Joel Brobecker
2017-06-17 21:23 ` 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=86o9trdib1.fsf@gmail.com \
--to=qiyaoltc@gmail.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=simon.marchi@ericsson.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