* About implementation of the Negative property of options.
@ 2021-04-28 12:36 gengqi-linux
2021-04-28 20:11 ` Joseph Myers
0 siblings, 1 reply; 6+ messages in thread
From: gengqi-linux @ 2021-04-28 12:36 UTC (permalink / raw)
To: gcc-patches
I have been fixing a bug. It involved the Negative property of options, and I have some confusion about it.
gcc/optc-gen.awk: 383
neg = opt_args("Negative", flags[i]);
if (neg != "")
idx = indices[neg]
else {
if (flag_set_p("RejectNegative", flags[i]))
idx = -1;
else {
if (opts[i] ~ "^[Wfgm]")
idx = indices[opts[i]];
else
idx = -1;
}
}
Above is the code that handles the ‘Nagetive’ property. I don't see why the 'idx' should be set -1 when 'RejectNegative'.
As I understand it, ‘Negative’ and ‘RejectNegative’ are similar name, but not related in implementation.
The following is my implementation about it:
--- a/gcc/doc/options.texi
+++ b/gcc/doc/options.texi
@@ -220,11 +220,7 @@ property is used.
The option will turn off another option @var{othername}, which is
the option name with the leading ``-'' removed. This chain action will
propagate through the @code{Negative} property of the option to be
-turned off. The driver will prune options, removing those that are
-turned off by some later option. This pruning is not done for options
-with @code{Joined} or @code{JoinedOrMissing} properties, unless the
-options have either @code{RejectNegative} property or the @code{Negative}
-property mentions an option other than itself.
+turned off.
As a consequence, if you have a group of mutually-exclusive
options, their @code{Negative} properties should form a circular chain.
diff --git a/gcc/optc-gen.awk b/gcc/optc-gen.awk
index 880ac77..d32354c 100644
--- a/gcc/optc-gen.awk
+++ b/gcc/optc-gen.awk
@@ -383,7 +383,9 @@ for (i = 0; i < n_opts; i++) {
if (neg != "")
idx = indices[neg]
else {
- if (flag_set_p("RejectNegative", flags[i]))
+ if (flag_set_p("Joined", flags[i]) \
+ || flag_set_p("JoinedOrMissing", flags[i]) \
+ || flag_set_p("Separate", flags[i]))
idx = -1;
else {
if (opts[i] ~ "^[Wfgm]")
diff --git a/gcc/opts-common.c b/gcc/opts-common.c
index 5e10ede..898e8d8 100644
--- a/gcc/opts-common.c
+++ b/gcc/opts-common.c
@@ -1039,11 +1039,12 @@ cancel_option (int opt_idx, int next_opt_idx, int orig_next_opt_idx)
if (cl_options [next_opt_idx].neg_index == opt_idx)
return true;
- if (cl_options [next_opt_idx].neg_index != orig_next_opt_idx)
- return cancel_option (opt_idx, cl_options [next_opt_idx].neg_index,
- orig_next_opt_idx);
+ if (cl_options [next_opt_idx].neg_index == orig_next_opt_idx
+ || cl_options [next_opt_idx].neg_index < 0)
+ return false;
- return false;
+ return cancel_option (opt_idx, cl_options [next_opt_idx].neg_index,
+ orig_next_opt_idx);
}
/* Filter out options canceled by the ones after them. */
@@ -1088,14 +1089,6 @@ prune_options (struct cl_decoded_option **decoded_options,
default:
gcc_assert (opt_idx < cl_options_count);
option = &cl_options[opt_idx];
- if (option->neg_index < 0)
- goto keep;
-
- /* Skip joined switches. */
- if ((option->flags & CL_JOINED)
- && (!option->cl_reject_negative
- || (unsigned int) option->neg_index != opt_idx))
- goto keep;
for (j = i + 1; j < old_decoded_options_count; j++)
{
@@ -1104,13 +1097,6 @@ prune_options (struct cl_decoded_option **decoded_options,
next_opt_idx = old_decoded_options[j].opt_index;
if (next_opt_idx >= cl_options_count)
continue;
- if (cl_options[next_opt_idx].neg_index < 0)
- continue;
- if ((cl_options[next_opt_idx].flags & CL_JOINED)
- && (!cl_options[next_opt_idx].cl_reject_negative
- || ((unsigned int) cl_options[next_opt_idx].neg_index
- != next_opt_idx)))
- continue;
if (cancel_option (opt_idx, next_opt_idx, next_opt_idx))
break;
}
--
2.7.4
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: About implementation of the Negative property of options.
2021-04-28 12:36 About implementation of the Negative property of options gengqi-linux
@ 2021-04-28 20:11 ` Joseph Myers
2021-04-30 1:55 ` Jim Wilson
0 siblings, 1 reply; 6+ messages in thread
From: Joseph Myers @ 2021-04-28 20:11 UTC (permalink / raw)
To: gengqi-linux; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: About implementation of the Negative property of options.
2021-04-28 20:11 ` Joseph Myers
@ 2021-04-30 1:55 ` Jim Wilson
2021-04-30 8:03 ` 回复:About " gengqi-linux
2021-04-30 17:51 ` Joseph Myers
0 siblings, 2 replies; 6+ messages in thread
From: Jim Wilson @ 2021-04-30 1:55 UTC (permalink / raw)
To: Joseph Myers; +Cc: gengqi-linux, gcc-patches
On Wed, Apr 28, 2021 at 1:11 PM Joseph Myers <joseph@codesourcery.com>
wrote:
> 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.
I added this to the riscv.opt file to create some new options for
demonstration purposes. The same changes probably work for other targets
too.
mfoo1=
Target Joined Var(riscv_isa_foo)
mfoo2=
Target Joined Var(riscv_isa_foo) RejectNegative
mfoo3=
Target Joined Var(riscv_isa_foo) Negative(mfoo3=)
mfoo4=
Target Joined Var(riscv_isa_foo) Negative(mfoo5=)
mfoo5=
Target Joined Var(riscv_isa_foo) Negative(mfoo4=)
mfoo6=
Target Joined Var(riscv_isa_foo) Negative(mfoo6=) RejectNegative
mfoo7=
Target Joined Var(riscv_isa_foo) Negative(mfoo8=) RejectNegative
mfoo8=
Target Joined Var(riscv_isa_foo) Negative(mfoo7=) RejectNegative
TargetVariable
int riscv_isa_foo = 0
Then I ran some commands to look at the cc1 option list.
rohan:2754$ ./xgcc -B./ -mfoo1=10 -mfoo1=20 tmp.c -v -S |& grep cc1
./cc1 -quiet -v -imultilib rv64imafdc/lp64d -iprefix
/home/jimw/FOSS/GCC/X-9-riscv64-elf/gcc/../lib/gcc/riscv64-unknown-elf/9.3.1/
-isystem ./include -isystem ./include-fixed tmp.c -quiet -dumpbase tmp.c
-mfoo1=10 -mfoo1=20 -march=rv64gc -mabi=lp64d -auxbase tmp -version -o tmp.s
rohan:2755$ ./xgcc -B./ -mfoo2=10 -mfoo2=20 tmp.c -v -S |& grep cc1
./cc1 -quiet -v -imultilib rv64imafdc/lp64d -iprefix
/home/jimw/FOSS/GCC/X-9-riscv64-elf/gcc/../lib/gcc/riscv64-unknown-elf/9.3.1/
-isystem ./include -isystem ./include-fixed tmp.c -quiet -dumpbase tmp.c
-mfoo2=10 -mfoo2=20 -march=rv64gc -mabi=lp64d -auxbase tmp -version -o tmp.s
rohan:2756$ ./xgcc -B./ -mfoo3=10 -mfoo3=20 tmp.c -v -S |& grep cc1
./cc1 -quiet -v -imultilib rv64imafdc/lp64d -iprefix
/home/jimw/FOSS/GCC/X-9-riscv64-elf/gcc/../lib/gcc/riscv64-unknown-elf/9.3.1/
-isystem ./include -isystem ./include-fixed tmp.c -quiet -dumpbase tmp.c
-mfoo3=10 -mfoo3=20 -march=rv64gc -mabi=lp64d -auxbase tmp -version -o tmp.s
rohan:2757$ ./xgcc -B./ -mfoo4=10 -mfoo4=20 tmp.c -v -S |& grep cc1
./cc1 -quiet -v -imultilib rv64imafdc/lp64d -iprefix
/home/jimw/FOSS/GCC/X-9-riscv64-elf/gcc/../lib/gcc/riscv64-unknown-elf/9.3.1/
-isystem ./include -isystem ./include-fixed tmp.c -quiet -dumpbase tmp.c
-mfoo4=10 -mfoo4=20 -march=rv64gc -mabi=lp64d -auxbase tmp -version -o tmp.s
rohan:2758$ ./xgcc -B./ -mfoo5=10 -mfoo5=20 tmp.c -v -S |& grep cc1
./cc1 -quiet -v -imultilib rv64imafdc/lp64d -iprefix
/home/jimw/FOSS/GCC/X-9-riscv64-elf/gcc/../lib/gcc/riscv64-unknown-elf/9.3.1/
-isystem ./include -isystem ./include-fixed tmp.c -quiet -dumpbase tmp.c
-mfoo5=10 -mfoo5=20 -march=rv64gc -mabi=lp64d -auxbase tmp -version -o tmp.s
rohan:2759$ ./xgcc -B./ -mfoo6=10 -mfoo6=20 tmp.c -v -S |& grep cc1
./cc1 -quiet -v -imultilib rv64imafdc/lp64d -iprefix
/home/jimw/FOSS/GCC/X-9-riscv64-elf/gcc/../lib/gcc/riscv64-unknown-elf/9.3.1/
-isystem ./include -isystem ./include-fixed tmp.c -quiet -dumpbase tmp.c
-mfoo6=20 -march=rv64gc -mabi=lp64d -auxbase tmp -version -o tmp.s
rohan:2760$ ./xgcc -B./ -mfoo7=10 -mfoo7=20 tmp.c -v -S |& grep cc1
./cc1 -quiet -v -imultilib rv64imafdc/lp64d -iprefix
/home/jimw/FOSS/GCC/X-9-riscv64-elf/gcc/../lib/gcc/riscv64-unknown-elf/9.3.1/
-isystem ./include -isystem ./include-fixed tmp.c -quiet -dumpbase tmp.c
-mfoo7=10 -mfoo7=20 -march=rv64gc -mabi=lp64d -auxbase tmp -version -o tmp.s
rohan:2761$ ./xgcc -B./ -mfoo7=10 -mfoo8=20 tmp.c -v -S |& grep cc1
./cc1 -quiet -v -imultilib rv64imafdc/lp64d -iprefix
/home/jimw/FOSS/GCC/X-9-riscv64-elf/gcc/../lib/gcc/riscv64-unknown-elf/9.3.1/
-isystem ./include -isystem ./include-fixed tmp.c -quiet -dumpbase tmp.c
-mfoo7=10 -mfoo8=20 -march=rv64gc -mabi=lp64d -auxbase tmp -version -o tmp.s
rohan:2762$
Note that only in the -mfoo6= case are the duplicate options removed from
the command line. So pruning options requires that you have both
RejectNegative and Negative pointing at yourself, which is not what the
documentation says.
The original bug report mentioned problems with picking the right multilib
if you have multiple conflicting options on the command line. But another
simpler way to show the problem is by mixing 32-bit and 64-bit arches on
the command line.
rohan:2546$ riscv64-unknown-elf-gcc -march=rv32gc -march=rv64gc -mabi=lp64d
tmp.c
/home/jimw/FOSS/install-riscv64/lib/gcc/riscv64-unknown-elf/10.2.0/../../../../riscv64-unknown-elf/bin/ld:
unrecognised emulation mode: elf3264lriscv
Supported emulations: elf64lriscv elf32lriscv
collect2: error: ld returned 1 exit status
rohan:2547$
This is because we have
#define XLEN_SPEC \
"%{march=rv32*:32}" \
"%{march=rv64*:64}" \
#define LINK_SPEC "\
-melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv \
which only works right if contradictory options are pruned.
I tried a gcc-9 tree that I have handy, and got the same result. Only in
the -mfoo6= case are the contradictory options pruned away, so this does
not appear to be due to a recent change, but rather has been working this
way for a while.
For the RISC-V port, adding the missing Negative lines to the
riscv.opt file is easy enough, I will just go ahead and do that. But we
might want to consider whether this design is correct, and how to fix the
docs to match reality.
Jim
^ permalink raw reply [flat|nested] 6+ messages in thread
* 回复:About implementation of the Negative property of options.
2021-04-30 1:55 ` Jim Wilson
@ 2021-04-30 8:03 ` gengqi-linux
2021-04-30 21:23 ` About " Jim Wilson
2021-04-30 17:51 ` Joseph Myers
1 sibling, 1 reply; 6+ messages in thread
From: gengqi-linux @ 2021-04-30 8:03 UTC (permalink / raw)
To: Joseph Myers, Jim Wilson; +Cc: gcc-patches, rjiejie, cooper.qu
Thanks for your replies.
On Thurs, Apr 29, 2021, utc+8
PM Joseph Myers <joseph@codesourcery.com> wrote:
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.
This is the real bug I met:
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568974.html
On Thurs, Apr 29, 2021, utc+8
Joseph Myers <joseph@codesourcery.com> wrote:
Note that only in the -mfoo6= case are the duplicate options removed from the command line. So pruning options requires that you have both RejectNegative and Negative pointing at yourself, which is not what the documentation says.
I also noticed a description error in the documentation:
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568977.html
The patch above can fix the bug I met, but the same modification may not work in older versions because a key commit “aebe10d48ccc217273ee8a4e2c3805ed1e173a78” is needed.
In my view, when I give the Negative property for '-march=' just like my patch do,
--> march=
--> -Target RejectNegative Joined
--> +Target RejectNegative Joined Negative(march=)
there should be enough information for the Driver to prune the extra '-march=' options, and this behavior should work well without the code added to gcc/opts-common.c from commit “aebe10d48ccc217273ee8a4e2c3805ed1e173a78" .
On the other hand, as Joseph Myers <joseph@codesourcery.com> tested:
mfoo3=
Target Joined Var(riscv_isa_foo) Negative(mfoo3=)
mfoo4=
Target Joined Var(riscv_isa_foo) Negative(mfoo5=)
mfoo5=
Target Joined Var(riscv_isa_foo) Negative(mfoo4=)
mfoo6=
Target Joined Var(riscv_isa_foo) Negative(mfoo6=) RejectNegative
mfoo7=
Target Joined Var(riscv_isa_foo) Negative(mfoo8=) RejectNegative
mfoo8=
Target Joined Var(riscv_isa_foo) Negative(mfoo7=) RejectNegative
I think -mfoo3=,-mfoo4,-mfoo5 should be pruned, and -mfoo6=,-mfoo7,-mfoo8 should also be pruned.
Compare -mfoo3=,-mfoo4,-mfoo5 with -mfoo6=,-mfoo7,-mfoo8, I think the RejectNegative may shouldn't bother with the Negative.
This is why I wrote on Wed Apr 28 12:36:11 GMT 2021
gcc/optc-gen.awk: 383
neg = opt_args("Negative", flags[i]);
if (neg != "")
idx = indices[neg]
else {
if (flag_set_p("RejectNegative", flags[i]))
idx = -1;
else {
if (opts[i] ~ "^[Wfgm]")
idx = indices[opts[i]];
else
idx = -1;
}
}
Above is the code that handles the ‘Nagetive’ property. I don't see why the 'idx' should be set -1 when 'RejectNegative'.
As I understand it, ‘Negative’ and ‘RejectNegative’ are similar name, but not related in implementation.
------------------------------------------------------------------
发件人:Jim Wilson <jimw@sifive.com>
发送时间:2021年4月30日(星期五) 10:02
收件人:Joseph Myers <joseph@codesourcery.com>
抄 送:gengqi-linux <gengqi@linux.alibaba.com>; gcc-patches <gcc-patches@gcc.gnu.org>
主 题:Re: About implementation of the Negative property of options.
On Wed, Apr 28, 2021 at 1:11 PM Joseph Myers <joseph@codesourcery.com> wrote:
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.
I added this to the riscv.opt file to create some new options for demonstration purposes. The same changes probably work for other targets too.
mfoo1=Target Joined Var(riscv_isa_foo)
mfoo2=
Target Joined Var(riscv_isa_foo) RejectNegative
mfoo3=
Target Joined Var(riscv_isa_foo) Negative(mfoo3=)
mfoo4=
Target Joined Var(riscv_isa_foo) Negative(mfoo5=)
mfoo5=
Target Joined Var(riscv_isa_foo) Negative(mfoo4=)
mfoo6=
Target Joined Var(riscv_isa_foo) Negative(mfoo6=) RejectNegative
mfoo7=
Target Joined Var(riscv_isa_foo) Negative(mfoo8=) RejectNegative
mfoo8=
Target Joined Var(riscv_isa_foo) Negative(mfoo7=) RejectNegative
TargetVariable
int riscv_isa_foo = 0
Then I ran some commands to look at the cc1 option list.
rohan:2754$ ./xgcc -B./ -mfoo1=10 -mfoo1=20 tmp.c -v -S |& grep cc1 ./cc1 -quiet -v -imultilib rv64imafdc/lp64d -iprefix /home/jimw/FOSS/GCC/X-9-riscv64-elf/gcc/../lib/gcc/riscv64-unknown-elf/9.3.1/ -isystem ./include -isystem ./include-fixed tmp.c -quiet -dumpbase tmp.c -mfoo1=10 -mfoo1=20 -march=rv64gc -mabi=lp64d -auxbase tmp -version -o tmp.s
rohan:2755$ ./xgcc -B./ -mfoo2=10 -mfoo2=20 tmp.c -v -S |& grep cc1
./cc1 -quiet -v -imultilib rv64imafdc/lp64d -iprefix /home/jimw/FOSS/GCC/X-9-riscv64-elf/gcc/../lib/gcc/riscv64-unknown-elf/9.3.1/ -isystem ./include -isystem ./include-fixed tmp.c -quiet -dumpbase tmp.c -mfoo2=10 -mfoo2=20 -march=rv64gc -mabi=lp64d -auxbase tmp -version -o tmp.s
rohan:2756$ ./xgcc -B./ -mfoo3=10 -mfoo3=20 tmp.c -v -S |& grep cc1
./cc1 -quiet -v -imultilib rv64imafdc/lp64d -iprefix /home/jimw/FOSS/GCC/X-9-riscv64-elf/gcc/../lib/gcc/riscv64-unknown-elf/9.3.1/ -isystem ./include -isystem ./include-fixed tmp.c -quiet -dumpbase tmp.c -mfoo3=10 -mfoo3=20 -march=rv64gc -mabi=lp64d -auxbase tmp -version -o tmp.s
rohan:2757$ ./xgcc -B./ -mfoo4=10 -mfoo4=20 tmp.c -v -S |& grep cc1
./cc1 -quiet -v -imultilib rv64imafdc/lp64d -iprefix /home/jimw/FOSS/GCC/X-9-riscv64-elf/gcc/../lib/gcc/riscv64-unknown-elf/9.3.1/ -isystem ./include -isystem ./include-fixed tmp.c -quiet -dumpbase tmp.c -mfoo4=10 -mfoo4=20 -march=rv64gc -mabi=lp64d -auxbase tmp -version -o tmp.s
rohan:2758$ ./xgcc -B./ -mfoo5=10 -mfoo5=20 tmp.c -v -S |& grep cc1
./cc1 -quiet -v -imultilib rv64imafdc/lp64d -iprefix /home/jimw/FOSS/GCC/X-9-riscv64-elf/gcc/../lib/gcc/riscv64-unknown-elf/9.3.1/ -isystem ./include -isystem ./include-fixed tmp.c -quiet -dumpbase tmp.c -mfoo5=10 -mfoo5=20 -march=rv64gc -mabi=lp64d -auxbase tmp -version -o tmp.s
rohan:2759$ ./xgcc -B./ -mfoo6=10 -mfoo6=20 tmp.c -v -S |& grep cc1
./cc1 -quiet -v -imultilib rv64imafdc/lp64d -iprefix /home/jimw/FOSS/GCC/X-9-riscv64-elf/gcc/../lib/gcc/riscv64-unknown-elf/9.3.1/ -isystem ./include -isystem ./include-fixed tmp.c -quiet -dumpbase tmp.c -mfoo6=20 -march=rv64gc -mabi=lp64d -auxbase tmp -version -o tmp.s
rohan:2760$ ./xgcc -B./ -mfoo7=10 -mfoo7=20 tmp.c -v -S |& grep cc1
./cc1 -quiet -v -imultilib rv64imafdc/lp64d -iprefix /home/jimw/FOSS/GCC/X-9-riscv64-elf/gcc/../lib/gcc/riscv64-unknown-elf/9.3.1/ -isystem ./include -isystem ./include-fixed tmp.c -quiet -dumpbase tmp.c -mfoo7=10 -mfoo7=20 -march=rv64gc -mabi=lp64d -auxbase tmp -version -o tmp.s
rohan:2761$ ./xgcc -B./ -mfoo7=10 -mfoo8=20 tmp.c -v -S |& grep cc1
./cc1 -quiet -v -imultilib rv64imafdc/lp64d -iprefix /home/jimw/FOSS/GCC/X-9-riscv64-elf/gcc/../lib/gcc/riscv64-unknown-elf/9.3.1/ -isystem ./include -isystem ./include-fixed tmp.c -quiet -dumpbase tmp.c -mfoo7=10 -mfoo8=20 -march=rv64gc -mabi=lp64d -auxbase tmp -version -o tmp.s
rohan:2762$
Note that only in the -mfoo6= case are the duplicate options removed from the command line. So pruning options requires that you have both RejectNegative and Negative pointing at yourself, which is not what the documentation says.
The original bug report mentioned problems with picking the right multilib if you have multiple conflicting options on the command line. But another simpler way to show the problem is by mixing 32-bit and 64-bit arches on the command line.
rohan:2546$ riscv64-unknown-elf-gcc -march=rv32gc -march=rv64gc -mabi=lp64d tmp.c
/home/jimw/FOSS/install-riscv64/lib/gcc/riscv64-unknown-elf/10.2.0/../../../../riscv64-unknown-elf/bin/ld: unrecognised emulation mode: elf3264lriscv
Supported emulations: elf64lriscv elf32lriscv
collect2: error: ld returned 1 exit status
rohan:2547$
This is because we have
#define XLEN_SPEC \
"%{march=rv32*:32}" \
"%{march=rv64*:64}" \
#define LINK_SPEC "\
-melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv \
which only works right if contradictory options are pruned.
I tried a gcc-9 tree that I have handy, and got the same result. Only in the -mfoo6= case are the contradictory options pruned away, so this does not appear to be due to a recent change, but rather has been working this way for a while.
For the RISC-V port, adding the missing Negative lines to the riscv.opt file is easy enough, I will just go ahead and do that. But we might want to consider whether this design is correct, and how to fix the docs to match reality.
Jim
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: About implementation of the Negative property of options.
2021-04-30 8:03 ` 回复:About " gengqi-linux
@ 2021-04-30 21:23 ` Jim Wilson
0 siblings, 0 replies; 6+ messages in thread
From: Jim Wilson @ 2021-04-30 21:23 UTC (permalink / raw)
To: gengqi-linux; +Cc: Joseph Myers, gcc-patches, rjiejie, cooper.qu
On Fri, Apr 30, 2021 at 1:03 AM gengqi-linux <gengqi@linux.alibaba.com>
wrote:
> Thanks for your replies.
>
I would suggest filing a bug report, and adding useful info from this
thread to the bug report. Then we can track it.
Jim
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: About implementation of the Negative property of options.
2021-04-30 1:55 ` Jim Wilson
2021-04-30 8:03 ` 回复:About " gengqi-linux
@ 2021-04-30 17:51 ` Joseph Myers
1 sibling, 0 replies; 6+ messages in thread
From: Joseph Myers @ 2021-04-30 17:51 UTC (permalink / raw)
To: Jim Wilson; +Cc: gcc-patches, gengqi-linux
On Thu, 29 Apr 2021, Jim Wilson wrote:
> Note that only in the -mfoo6= case are the duplicate options removed from
> the command line. So pruning options requires that you have both
> RejectNegative and Negative pointing at yourself, which is not what the
> documentation says.
Thanks for the example.
There are definitely cases with RejectNegative that do not have the
Negative semantics and so should not have any pruning done (for example,
-Wa, is a JoinedOrMissing RejectNegative option). I don't know if any
such options have Negative specified, but I tend to think they shouldn't.
I think proper use of Negative should be to define equivalence classes of
options, such that only the last such option (with its corresponding
argument, if any) is in effect. That is, it would naturally be completely
orthogonal to Joined, JoinedOrMissing and RejectNegative.
As part of implmenting anything like the above, it's probably desirable to
review existing uses of Negative to identify any which do not form a
circular chain of options, or where the pruning isn't currently in effect
because of any rules (documented or implemented) about interaction with
Joined, JoinedOrMissing and RejectNegative. In some cases, it's probably
necessary to change the .opt files (to give options the correct semantics,
or to keep them having the correct semantics). If there are lots of cases
where the semantics are correct at present but my proposal above means the
.opt files need to change, we should look at some examples and consider
revisiting my proposal. When changes (to either option handling code or
.opt files) fix user-visible problems with how options are handled at
present, adding testcases to the testsuite would be a good idea, at least
for some representative examples.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-04-30 21:23 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-28 12:36 About implementation of the Negative property of options gengqi-linux
2021-04-28 20:11 ` Joseph Myers
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
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).