In our fork of gcc we go from "xpulpv0" to "xpulpv3".
Technically, the versioning was not done 100% correctly (since
some changes didn't require a major version bump) but either way
I hit this issue when porting our patches to a newer gcc.
Currently, I work around it with an additional check.
Robe
The gcc-bugs mailing list is for automated mails from our Bugzilla
database. Bug reports should be entered into Bugzilla, and discussions
should happen in Bugzilla or on a more apppropriate mailing list
(because most GCC devs do not routinely read the gcc-bugs mails).
Hi Robert:
My assumption is the version should never be 0.0, at least 0.1, so it
is treated as 2p0,
but I didn't check if the input is really 0p0 or 0, that's kind of bug
we need to fix.
And I am not familiar with PULP stuff, does it mean PULP really uses
version 0.0,
and intend to implement mult
When giving gcc a -march string with a custom extension of
version 0 (for example pulpv0) then gcc will think assign in the
default version of 2p0.
In gcc/common/config/riscv/riscv-common.c the function
riscv_subset_list::parsing_subset_version falls back to the
default version (2p0) when parsing
