Committed with coding style fixing.
On Wed, Jul 1, 2020 at 11:16 AM Kito Cheng <kito.ch...@sifive.com> 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 make much sense to specify > > a version with g and assume it is correct for all of imafd. Similarly > > with the implied extensions, e.g. dXpY is expanded to fXpY_dXpY, > > though in this case it is likely that f and d numbers will remain > > compatible. And q too. Still it looks a bit funny to be making that > > assumption and there probably will be other examples where the > > versions of the implied extensions won't match the specified > > extension. Actually I see that f implies Zicsr, and those two have > > different version numbers, we just haven't implemented Zicsr yet. We > > are correctly implementing the rules as specified, the rules just > > don't make sense here. We probably need to file an issue against the > > riscv-isa-manual project for a clarification of how to handle this > > stuff. > > 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 could deprecate the version for G in GCC 11 and then drop > that in GCC 12? > For riscv-isa-manual, we could ask them to add a note about the G > don't accept version? > What do you think about this? > > And the -misa-spec is supported on the binutils side, so I guess it's > time to start to improve > those things on GCC now. > > [1] > https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aZhMG7NIVTk/m/hX2BRWsMEQAJ > > Thanks :) > > > > > Jim
