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.
Robert On 6/23/21 11:19 AM, Kito Cheng wrote: > 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 multiple-version of that on GCC? > > On Mon, Jun 21, 2021 at 10:07 AM Robert Balas via Gcc-bugs > <gcc-bugs@gcc.gnu.org> wrote: >> >> 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 if the major and minor version >> are both zero (which is the case for the string "pulpv0"). This >> means both "pulpv0" and "pulpv2" will get assigned the version >> 2p0. Looks wrong to me. >> >> Robert
