On 2022/05/19 12:40, Nelson Chu wrote: > Seems like gcc and llvm have already committed this patch, so LGTM, committed.
Sorry, the same change is applied to LLVM but not yet on GCC (because I forgot to add "Signed-off-by" line). I sent PATCH v2 to gcc-patches today so that would be okay. On PATCH v2, I made the same change to gcc/config/riscv/arch-canonicalize script (not just gcc/common/config/riscv/riscv-common.cc). <https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595373.html> Thanks, Tsukasa > > Thanks > Nelson > > On Mon, Apr 25, 2022 at 11:53 AM Palmer Dabbelt <pal...@dabbelt.com> wrote: >> >> On Mon, 28 Mar 2022 17:12:55 PDT (-0700), Palmer Dabbelt wrote: >>> On Mon, 28 Mar 2022 06:12:01 PDT (-0700), binut...@sourceware.org wrote: >>>> This commit fixes canonical extension order to follow the RISC-V ISA >>>> Manual draft-20210402-1271737 or later. >>>> >>>> bfd/ChangeLog: >>>> >>>> * elfxx-riscv.c (riscv_recognized_prefixed_ext): Fix "K" extension >>>> prefix to be placed before "J". >>>> --- >>>> bfd/elfxx-riscv.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/bfd/elfxx-riscv.c b/bfd/elfxx-riscv.c >>>> index cb2cc146c04..1219a7b44d4 100644 >>>> --- a/bfd/elfxx-riscv.c >>>> +++ b/bfd/elfxx-riscv.c >>>> @@ -1338,7 +1338,7 @@ riscv_recognized_prefixed_ext (const char *ext) >>>> } >>>> >>>> /* Canonical order for single letter extensions. */ >>>> -static const char riscv_ext_canonical_order[] = "eigmafdqlcbjktpvn"; >>>> +static const char riscv_ext_canonical_order[] = "eigmafdqlcbkjtpvn"; >>>> >>>> /* Array is used to compare the orders of standard extensions quickly. */ >>>> static int riscv_ext_order[26] = {0}; >>> >>> Looks like this was just a bug in binutils: K went from being >>> unspecified to specified in 271737 ("Define canonical location of K >>> extension in ISA string"), thus it was never allowed at that other bit >>> position. >>> >>> It looks like GCC also has this wrong, which sort of doubles the >>> headache: now we've got this odd coupling between the GCC version and >>> binutils version. I'm not sure what the right thing is to do here: >>> certainly rejecting the valid ISA string should be fixed, but I think we >>> might need to accept the invalid one for compatibility reasons. That'll >>> be a headache to implement, though, so I'm not sure it's worth it. >>> >>> Maybe someone has a clever solution to this one? >> >> After seeing the GCC patch go by, I think the clever solution here is to >> just say that we never accepted any J stuff in the first place so it's >> not a compatibility break. >
