From: Joseph Myers <joseph@codesourcery.com>
To: gengqi-linux <gengqi@linux.alibaba.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: About implementation of the Negative property of options.
Date: Wed, 28 Apr 2021 20:11:02 +0000 [thread overview]
Message-ID: <alpine.DEB.2.22.394.2104282003170.115529@digraph.polyomino.org.uk> (raw)
In-Reply-To: <f81f300a-242d-488c-bf07-861aa132e629.gengqi@linux.alibaba.com>
On Wed, 28 Apr 2021, gengqi-linux via Gcc-patches wrote:
> I have been fixing a bug. It involved the Negative property of options,
> and I have some confusion about it.
Could you please explain the bug at the *user-visible* level? That is,
the particular options passed to the compiler, how those options behave,
and how you think they should behave instead.
Once we know the *user-visible* issue under discussion, we can consider
what the compiler's internal datastructures should look like to achieve
the desired behavior (if indeed it is desired). Once we've worked out
what the internal datastructures should look like, we can consider how the
opt*.awk machinery should generate those datastructures from the .opt
files.
> Above is the code that handles the ‘Nagetive’ property. I don't see why
> the 'idx' should be set -1 when 'RejectNegative'.
Presumably because the handling of -1 somewhere in the compiler is
considered appropriate for RejectNegative options. If you don't think it
is, again, can you give an example at the user-visible level of a
RejectNegative option for which that value of -1 results in inappropriate
user-visible behavior? Then we can consider several possibilities for
where the bug is:
* Maybe the handling of -1 is incorrect (but the setting of -1 is
correct).
* Maybe the handling of -1 is correct (but the setting of -1 is
incorrect).
* Maybe the option shouldn't be RejectNegative at all, but the existing
handling is appropriate for some other RejectNegative options.
* Maybe in fact the option is being handled correctly, and changing the
handling of -1 would result in it being handled incorrectly.
* Maybe in fact the option is being handled correctly, but some of the
relevant option-handling code is still conceptually confused and could be
simplified without changing anything user-visible.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2021-04-28 20:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-28 12:36 gengqi-linux
2021-04-28 20:11 ` Joseph Myers [this message]
2021-04-30 1:55 ` Jim Wilson
2021-04-30 8:03 ` 回复:About " gengqi-linux
2021-04-30 21:23 ` About " Jim Wilson
2021-04-30 17:51 ` Joseph Myers
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=alpine.DEB.2.22.394.2104282003170.115529@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=gengqi@linux.alibaba.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).