Re: [PATCH v3 04/13] bfd/RISC-V: Zv{b,k}* imply Zve32x

On 21.07.2026 04:24, Nelson Chu wrote:
> On Fri, Jun 19, 2026 at 7:48 PM Jan Beulich <[email protected]> wrote:
>>
>> The specification is quite explicit about this.
> 
> OK, thanks.

Hmm, thanks, but you giving an okay here contradicts what you say / quote
below. (Plus, see below, the v3 arrangement is wrong anyway.)

>  As for ...
> 
>> Is the placement of "zve32x" after "zvbb" / "zvbc" actually correct? While
>> riscv_compare_subsets() indeed does a mere strcasecmp() past "zv", it
>> seems unlikely to be mere chance that Zve* come ahead of all other Zv* in
>> riscv_supported_std_z_ext[].
> 
> ... I checked the ISA spec again from here,
> https://github.com/riscv/riscv-isa-manual/blob/main/src/unpriv/naming.adoc#additional-standard-unprivileged-extension-names,
> 
> "If multiple ext:z[] extensions are named, they should be ordered
> first by category, then alphabetically within a category — for
> example, Zicsr_Zifencei_Ztso"
> So I think since the alphabetical order, zve* should be placed after
> zvb*.

Well, first of all we need to heed the comment ahead of the table, no
matter how cryptic / vague / ambiguous it is:

/* Please added in order since this table is only run once time.  */

zve* _must_ come after everything mentioning it as a dependency. Hence
in v4 it now is:

--- a/bfd/elfxx-riscv.c
+++ b/bfd/elfxx-riscv.c
@@ -1239,11 +1239,30 @@ static const struct riscv_implicit_subse
   {"zvfhmin", "+zve32f", check_implicit_always},
   {"zvfbfwma", "+zfbfmin,+zvfbfmin", check_implicit_always},
   {"zvfbfmin", "+zve32f", check_implicit_always},
+
+  {"zvbb", "+zvkb", check_implicit_always},
+  {"zvkng", "+zvkn,+zvkg", check_implicit_always},
+  {"zvknc", "+zvkn,+zvbc", check_implicit_always},
+  {"zvkn", "+zvkned,+zvknhb,+zvkb,+zvkt", check_implicit_always},
+  {"zvksg", "+zvks,+zvkg", check_implicit_always},
+  {"zvksc", "+zvks,+zvbc", check_implicit_always},
+  {"zvks", "+zvksed,+zvksh,+zvkb,+zvkt", check_implicit_always},
+
+  {"zvbc", "+zve32x", check_implicit_always},
+  {"zvkb", "+zve32x", check_implicit_always},
+  {"zvkg", "+zve32x", check_implicit_always},
+  {"zvkned", "+zve32x", check_implicit_always},
+  {"zvknha", "+zve32x", check_implicit_always},
+  {"zvknhb", "+zve32x", check_implicit_always},
+  {"zvksed", "+zve32x", check_implicit_always},
+  {"zvksh", "+zve32x", check_implicit_always},
+
   {"zve64d", "+d,+zve64f", check_implicit_always},
   {"zve64f", "+zve32f,+zve64x,+zvl64b", check_implicit_always},
   {"zve32f", "+f,+zve32x,+zvl32b", check_implicit_always},
   {"zve64x", "+zve32x,+zvl64b", check_implicit_always},
   {"zve32x", "+zvl32b,+zicsr", check_implicit_always},
+
   {"zvl65536b", "+zvl32768b", check_implicit_always},
   {"zvl32768b", "+zvl16384b", check_implicit_always},
   {"zvl16384b", "+zvl8192b", check_implicit_always},
@@ -1303,13 +1322,6 @@ static const struct riscv_implicit_subse
   {"zk", "+zkn,+zkr,+zkt", check_implicit_always},
   {"zkn", "+zbkb,+zbkc,+zbkx,+zkne,+zknd,+zknh", check_implicit_always},
   {"zks", "+zbkb,+zbkc,+zbkx,+zksed,+zksh", check_implicit_always},
-  {"zvbb", "+zvkb", check_implicit_always},
-  {"zvkng", "+zvkn,+zvkg", check_implicit_always},
-  {"zvknc", "+zvkn,+zvbc", check_implicit_always},
-  {"zvkn", "+zvkned,+zvknhb,+zvkb,+zvkt", check_implicit_always},
-  {"zvksg", "+zvks,+zvkg", check_implicit_always},
-  {"zvksc", "+zvks,+zvbc", check_implicit_always},
-  {"zvks", "+zvksed,+zvksh,+zvkb,+zvkt", check_implicit_always},
 
   {"sdtrig", "+zicsr", check_implicit_always},
 

This requirement also gets in the way of alphabetical sorting (e.g.
zvknc has to come ahead of zvbc). Yet of course the term "category"
is fuzzy as well. Given the v4 hunks above, what supposed order is
it that you read out of the text you quote? What exactly are the
"categories" specifically here?

And then, is e.g. zk* coming after zv* correct? That's hard to tell
already simply because there's V as an extension, but there's no K.
Or is e.g. zicntr and zihpm living very early in the table not
requiring not calling for zicfilp / zicfiss to move up as well? Or
wouldn't zclsd then belong together with zcd and zcf? C / Zc* in
particular mix pretty unhelpfully with other extensions, when it
comes to determining "categories".

>  The order of riscv_supported_* tables doesn't affect the final
> output, but it would be good to be maintained in the right order.

Right, but that of riscv_implicit_subsets[] does.

Jan