public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jim Wilson <jimw@sifive.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: gengqi-linux <gengqi@linux.alibaba.com>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: About implementation of the Negative property of options.
Date: Thu, 29 Apr 2021 18:55:34 -0700	[thread overview]
Message-ID: <CAFyWVaY+R_b3ccAfGC2NOiLZzYA1zQZFYQM2QSCSdNK2Y6e-GQ@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2104282003170.115529@digraph.polyomino.org.uk>

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

  reply	other threads:[~2021-04-30  1:55 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
2021-04-30  1:55   ` Jim Wilson [this message]
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=CAFyWVaY+R_b3ccAfGC2NOiLZzYA1zQZFYQM2QSCSdNK2Y6e-GQ@mail.gmail.com \
    --to=jimw@sifive.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gengqi@linux.alibaba.com \
    --cc=joseph@codesourcery.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).