On Tue, Jun 3, 2025 at 12:44 AM Robin Dapp <rdapp....@gmail.com> wrote: > > > 1. riscv64-linux-gcc -march=rv64gc -march=foo-cpu -mtune=foo-cpu > > 2. riscv64-linux-gcc -march=rv64gc -march=foo-cpu > > 3. riscv64-linux-gcc -march=rv64gc -march=unset -mtune=unset -mcpu=foo-cpu > > > > Preference to me: > > - Prefer option 1. > > - Less prefer option 3. (acceptable but I don't like) > > - Strongly dislike option 2. > > My order of preference would be (unsurprisingly): > 2, 1, 3 > > I realize that might be a minority opinion. > > IMHO compilers are already difficult enough, the shorter the "compile/tune for > this CPU/profile" option, the better. > > -- > Regards > Robin
I prefer option 3. The ARM port's implementation of -march=unset has reinforced my preference for option 3. I disagree with option 1 and strongly disagree with option 2. > I can buy into the first point to some degree but IMHO it's not much more complicated. > > The second point I'm not so sure about. Why have we lost anything? All we > now > can do is use a shorthand CPU name instead of a lengthy arch string and > -march=lower -mcpu=higher is still available, as well as the other way around. > > And the third point is IMHO exaggerated. We're at the beginning of stage 1 > when more experimental things hit the trunk that can easily be adjusted. So > neither is anything done hastily nor do I believe the implications are that > far > reaching. > > You could just have said something like: "Is this set in stone already? In > order to achieve what you want we could also introduce an -march=unset and > -mtune=unset instead". > > IMHO there is enough difference in aarch64's and riscv's extension model that > it warrants doing some things not in their exact same way. aarch64's arch > strings don't regularly exceed a line. I recognize that others may have different preferences and may support what I oppose, but I want to highlight a significant process issue. On May 22, a discussion was initiated via https://github.com/riscv-non-isa/riscv-toolchain-conventions/issues/88 . The very next day, May 23, this commit was merged https://gcc.gnu.org/git/?p=gcc.git&a=commit;h=4a182418c89666e7594bcb0e5edc5194aa147910 I noticed no evidence of any discussion taking place. If not for the comment noting, "Seems it already merged into gcc upstream" (https://github.com/riscv-non-isa/riscv-toolchain-conventions/issues/88#issuecomment-2906504108), I would have been unaware of this. (Although I'm subscribed to the repository, I don't closely monitor every message, and this comment caught my attention by chance.) I posted my response (https://github.com/riscv-non-isa/riscv-toolchain-conventions/issues/88#issuecomment-2906934118 ), but after a week without response (with one account giving me +1, though), I decided to raise the issue on this mailing list. (As I'm not subscribed to the list, I had to configure neomutt and msmtp, download the mbox file from https://inbox.sourceware.org/gcc-patches/ , and use neomutt -f patch.mbox to reply.)
