Thanks for your replies. On Thurs, Apr 29, 2021, utc+8 PM Joseph Myers <jos...@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 <jos...@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 <jos...@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 <j...@sifive.com> 发送时间：2021年4月30日(星期五) 10:02 收件人：Joseph Myers <jos...@codesourcery.com> 抄 送：gengqi-linux <gen...@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 <jos...@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
