* [PATCH 0/1] RISC-V: Fix canonical extension order (K and J) @ 2022-03-28 13:12 Tsukasa OI 2022-03-28 13:12 ` [PATCH 1/1] " Tsukasa OI 0 siblings, 1 reply; 6+ messages in thread From: Tsukasa OI @ 2022-03-28 13:12 UTC (permalink / raw) To: Tsukasa OI; +Cc: binutils This commit fixes canonical extension order... from: "J" -> "K" to : "K" -> "J" as per the RISC-V ISA Manual draft-20210402-1271737 or later. This bug in the GNU Binutils is currently harmless because neither J nor Zj* extensions are implemented. Intention of this commit is for future- proofness. References: <https://github.com/riscv/riscv-isa-manual/commit/1271737463c04cacd98320d820a38f66d1c87dae> <https://github.com/riscv/riscv-isa-manual/releases/tag/draft-20210402-1271737> Tsukasa OI (1): RISC-V: Fix canonical extension order (K and J) bfd/elfxx-riscv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) base-commit: b8e92c571baed4e794bd62b7bf417fa8bbaf5c95 -- 2.32.0 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 1/1] RISC-V: Fix canonical extension order (K and J) 2022-03-28 13:12 [PATCH 0/1] RISC-V: Fix canonical extension order (K and J) Tsukasa OI @ 2022-03-28 13:12 ` Tsukasa OI 2022-03-29 0:12 ` Palmer Dabbelt 0 siblings, 1 reply; 6+ messages in thread From: Tsukasa OI @ 2022-03-28 13:12 UTC (permalink / raw) To: Tsukasa OI; +Cc: binutils 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}; -- 2.32.0 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/1] RISC-V: Fix canonical extension order (K and J) 2022-03-28 13:12 ` [PATCH 1/1] " Tsukasa OI @ 2022-03-29 0:12 ` Palmer Dabbelt 2022-04-25 3:52 ` Palmer Dabbelt 0 siblings, 1 reply; 6+ messages in thread From: Palmer Dabbelt @ 2022-03-29 0:12 UTC (permalink / raw) To: binutils; +Cc: research_trasio, binutils On Mon, 28 Mar 2022 06:12:01 PDT (-0700), binutils@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? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/1] RISC-V: Fix canonical extension order (K and J) 2022-03-29 0:12 ` Palmer Dabbelt @ 2022-04-25 3:52 ` Palmer Dabbelt 2022-05-19 3:40 ` Nelson Chu 0 siblings, 1 reply; 6+ messages in thread From: Palmer Dabbelt @ 2022-04-25 3:52 UTC (permalink / raw) To: binutils; +Cc: binutils On Mon, 28 Mar 2022 17:12:55 PDT (-0700), Palmer Dabbelt wrote: > On Mon, 28 Mar 2022 06:12:01 PDT (-0700), binutils@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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/1] RISC-V: Fix canonical extension order (K and J) 2022-04-25 3:52 ` Palmer Dabbelt @ 2022-05-19 3:40 ` Nelson Chu 2022-05-22 9:35 ` Tsukasa OI 0 siblings, 1 reply; 6+ messages in thread From: Nelson Chu @ 2022-05-19 3:40 UTC (permalink / raw) To: Palmer Dabbelt; +Cc: Binutils Seems like gcc and llvm have already committed this patch, so LGTM, committed. Thanks Nelson On Mon, Apr 25, 2022 at 11:53 AM Palmer Dabbelt <palmer@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), binutils@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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/1] RISC-V: Fix canonical extension order (K and J) 2022-05-19 3:40 ` Nelson Chu @ 2022-05-22 9:35 ` Tsukasa OI 0 siblings, 0 replies; 6+ messages in thread From: Tsukasa OI @ 2022-05-22 9:35 UTC (permalink / raw) To: Nelson Chu, Palmer Dabbelt, Kito Cheng; +Cc: Binutils, GCC Patches 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 <palmer@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), binutils@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. > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-05-22 9:35 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-03-28 13:12 [PATCH 0/1] RISC-V: Fix canonical extension order (K and J) Tsukasa OI 2022-03-28 13:12 ` [PATCH 1/1] " Tsukasa OI 2022-03-29 0:12 ` Palmer Dabbelt 2022-04-25 3:52 ` Palmer Dabbelt 2022-05-19 3:40 ` Nelson Chu 2022-05-22 9:35 ` Tsukasa OI
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).