RISC-V: Parsing custom extension that is version 0

RISC-V: Parsing custom extension that is version 0

[Robert Balas]

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

Re: RISC-V: Parsing custom extension that is version 0

[Kito Cheng]

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

Re: RISC-V: Parsing custom extension that is version 0

[Jonathan Wakely]

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).

Re: RISC-V: Parsing custom extension that is version 0

[Robert Balas]

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