public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Simon Marchi <simon.marchi@ericsson.com>
Cc: qiyaoltc@gmail.com, simon.marchi@polymtl.ca,	gdb-patches@sourceware.org
Subject: Re: [PATCH 0/5] Remove a few hurdles of compiling with clang
Date: Tue, 13 Jun 2017 14:38:00 -0000	[thread overview]
Message-ID: <83k24g3qcx.fsf@gnu.org> (raw)
In-Reply-To: <b69c7255-122b-cc25-005c-f16f34cffc4a@ericsson.com> (message from	Simon Marchi on Tue, 13 Jun 2017 12:23:27 +0200)

> From: Simon Marchi <simon.marchi@ericsson.com>
> Date: Tue, 13 Jun 2017 12:23:27 +0200
> 
> 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?

Let's not forget that code submitted by someone who is willing to do
the work stays in GDB even when that someone is no longer willing to
support that compiler.  So there are additional factors to consider
when making this decision.

> /home/emaisin/src/binutils-gdb/gdb/nat/x86-dregs.c:209:7: error: variable 'i' is incremented both in the loop header and in the loop body [-Werror,-Wfor-loop-analysis]
>       i++;
>       ^
> /home/emaisin/src/binutils-gdb/gdb/nat/x86-dregs.c:199:32: note: incremented here
>   ALL_DEBUG_ADDRESS_REGISTERS (i)
>                                ^

Why is incrementing a loop variable in the body an error?  It's
perfectly valid code.

> I think
> that eliminating the error like this is better than adding -Wno-for-loop-analysis, because
> if I wrote code like this and it was actually a mistake, I would like the compiler to tell
> me.

Does clang have the equivalent of "#pragma push"?  If it does, we
could disable this warning only for clang and only for that code
snippet.

  parent reply	other threads:[~2017-06-13 14:38 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 2/5] gdb: Use -Werror when checking for (un)supported warning flags Simon Marchi
2017-06-10 19:58 ` [PATCH 3/5] gdb: Add -Wno-mismatched-tags Simon Marchi
2017-06-10 19:58 ` [PATCH 1/5] gdb: Pass -x c++ to the compiler 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-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 [this message]
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
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=83k24g3qcx.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=qiyaoltc@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).