Hi Jim:
> I think it is reasonable to start a discussion in riscv-isa-manual, to
> try to get an official answer for what is valid and how to interpret
> it, instead of just making up our own rules.
Agree, issue[1] created on riscv-isa-manual.
[1] https://github.com/riscv/riscv-isa-manual/issues/
On Tue, Jun 30, 2020 at 8:16 PM Kito Cheng wrote:
> I agree the version of G is kind of problematic for GCC implementation,
> That reminds me there was a long discussion[1] last year,
> The conclusion is version of G is too confusing, it might just don't
> accept any version for G.
> I thought it
Committed with coding style fixing.
On Wed, Jul 1, 2020 at 11:16 AM Kito Cheng wrote:
>
> Hi Jim:
>
> > This isn't a criticism of your patch, but I noticed while looking at
> > this that we accept gXpY and expand to iXpY_mXpY_ etc. However, imafd
> > are all numbered independently. It doesn't m
Hi Jim:
> This isn't a criticism of your patch, but I noticed while looking at
> this that we accept gXpY and expand to iXpY_mXpY_ etc. However, imafd
> are all numbered independently. It doesn't make much sense to specify
> a version with g and assume it is correct for all of imafd. Similarly
On Mon, Jun 29, 2020 at 7:00 PM Kito Cheng wrote:
> - Arch version should preserved if user explicitly specified the version.
> e.g.
> After normalize, -march=rv32if3d should be -march=rv32i_f3p0d
> instead of-march=rv32ifd.
This looks good to me.
> +explicit_version_p(false)
I'd
- Arch version should preserved if user explicitly specified the version.
e.g.
After normalize, -march=rv32if3d should be -march=rv32i_f3p0d
instead of-march=rv32ifd.
gcc/ChangeLog:
* common/config/riscv/riscv-common.c(riscv_subset_t): New field
added.
(riscv_sub
