public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).