From: Chen Gang <gang.chen.5i5j@gmail.com>
To: Pedro Alves <palves@redhat.com>, Joel Brobecker <brobecker@adacore.com>
Cc: Mark Kettenis <mark.kettenis@xs4all.nl>,
amodra@gmail.com, gbenson@redhat.com, michael.sturm@intel.com,
walfred.tedeschi@intel.com, binutils@sourceware.org,
gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb/i387-tdep.c: Avoid warning for "-Werror=strict-overflow"
Date: Sat, 04 Oct 2014 05:12:00 -0000 [thread overview]
Message-ID: <542F831D.1000502@gmail.com> (raw)
In-Reply-To: <542EE1BF.7060203@redhat.com>
On 10/4/14 1:49, Pedro Alves wrote:
> On 10/03/2014 05:44 PM, Joel Brobecker wrote:
>>>> Sorry, but obfuscating code to make compilers happy is *not* the way to go.
>>>>
>>>
>>> OK, I can understand, but for me, these is no other better ways for it,
>>> except let gdb give up "-Werror" (if always need "--disable-werror"
>>> during "configure").
>>
>> I have to agree with Mark on this one, the proposed solution looks
>> awful. There has to be another way. Maybe declaring a local constant
>> whose value is I387_XMM0_REGNUM (tdep)?
>
> Likely, after transformations and intra-procedural analyses, gcc would
> end up with the same.
>
> This:
>
> for (i = I387_ST0_REGNUM (tdep); i < I387_XMM0_REGNUM (tdep); i++)
>
> always iterates exactly 16 times, because I387_XMM0_REGNUM
> is defined like:
>
> #define I387_XMM0_REGNUM(tdep) (I387_ST0_REGNUM (tdep) + 16)
>
> An alternative I think might work would be to give that magic
> 16 constant a name, say:
>
> #define I387_NUM_ST_REGS 16
>
> and then do:
>
> for (i = 0; i < i < I387_NUM_ST_REGS; i++)
> {
> int r = I387_ST0_REGNUM (tdep) + i;
>
> ... use 'r' instead of 'i' ...
> }
>
OK, thanks. It is really one way, it is a little better than my original
way. But for me, it is still not a good idea: it introduces a new macro
and a new variable for each area (originally, it is only one statement).
For me, "-Werror" need always be optional, but not mandatory.
Compiler is our helper, but we are in charge of the final code. So we
should notice about all compiler's 'advice'. Commonly, 'advice' is
always valuable, but may not always be suitable for oneself.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
next prev parent reply other threads:[~2014-10-04 5:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-03 15:24 Chen Gang
2014-10-03 15:46 ` Mark Kettenis
2014-10-03 16:02 ` Chen Gang
2014-10-03 16:44 ` Joel Brobecker
2014-10-03 18:47 ` Pedro Alves
2014-10-04 5:12 ` Chen Gang [this message]
2014-10-06 8:41 ` Pedro Alves
2014-10-06 13:29 ` Chen Gang
2014-10-10 11:22 ` Chen Gang
2014-10-09 10:06 ` Walfred Tedeschi
2014-10-09 11:20 ` 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=542F831D.1000502@gmail.com \
--to=gang.chen.5i5j@gmail.com \
--cc=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=brobecker@adacore.com \
--cc=gbenson@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=mark.kettenis@xs4all.nl \
--cc=michael.sturm@intel.com \
--cc=palves@redhat.com \
--cc=walfred.tedeschi@intel.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