Patch set committed :) On Wed, Nov 18, 2020 at 1:43 PM Kito Cheng <kito.ch...@gmail.com> wrote:
> >> Current GCC implementation is RISC-V ISA 2.2, this patch set implement > v20190608 and v20191213, and also add option > -misa-spec=[2.2|20190608|20191213] to change the default ISA spec version. > >> > >> There is one major incompatible > >> > >> That option will effect the default version of each sub-extension, for > example I-extension is 2.0 for 2.2 and 2.1 for v20190608 and v20191213. > >> > >> We also update the -march parser to fit the latest standard, the > canonical ordering for multi-letter, drop version support for G extension, > and we also omitted the version for unrecognized extension. > >> > >> And we add an special rule for G extension, imafd can't appear again if > G extension is present, but zicsr and zifencei can. > >> > >> The default ISA spec will keep on 2.2, and change that in next GCC > release. > > > > > > This patch series looks OK to me with minor fixes for the things I > pointed out. > > Thanks for reviewing, I'll commit that after fixing those issues and > testing again :) > > > I assume Nelson Chu will look at adding the missing zifencei binutils > support? > > Nelson has worked before, but got stuck due to arch implication rule, > i, g, zifencei and zicsr... > And now he plan to refer GCC implementation on binutils side after I > commit :P > > https://github.com/riscv/riscv-isa-manual/issues/575 > > > Maybe we should add an attribute for the isa-spec? This is redundant > with the arch spec, but might be easier for some folk to handle. Just one > version number instead of 6 version numbers. Though I suppose if we have > both we might have to deal with accidental conflicts between the two. We > would need a binutils patch first. This can be fixed later if it makes > sense to do it. > > I've considered that before but it seems like getting more confused, > since arch string can specify the version for each extension which can > override ISA-spec, but I guess more info is not harmful, I think we > can create an issue on psabi doc and continue discuss there. >
