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

[Jan Beulich]

On 22.06.2026 10:47, Jiawei wrote:
> I checked this locally with current binutils using as-new/readelf.
> 
> For the ordering question, the canonical order does not seem to come 
> from the
> order in riscv_supported_std_z_ext[]. riscv_compare_subsets() compares Z
> extensions by the character after 'z' and then by a case-insensitive suffix
> comparison. For Zv* extensions, this means the current canonical order is
> roughly:
> 
> zvbb, zvbc, zve32x, zvkb, zvkg, zvkn*, zvks*
> 
> The assembler/readelf tests confirm this. For example, both
> 
> -march=rv32i_zvbc_zve32x
> -march=rv32i_zve32x_zvbc
> 
> are canonicalized with zvbc before zve32x, while zvkb/zvkg/zvkn*/zvks* are
> placed after zve32x. So the ordering in the updated imply.d output looks
> consistent with the current canonicalization rule.
> 
> However, while testing the implied-dependency change, I noticed another
> possible issue. With the new implicit rows, an input such as
> 
> -march=rv32i_zvbc
> 
> is canonicalized as:
> 
> rv32i2p1_zvbc1p0_zve32x1p0
> 
> whereas explicitly specifying zve32x, for example
> 
> -march=rv32i_zvbc_zve32x
> 
> produces:
> 
> rv32i2p1_zicsr2p0_zvbc1p0_zve32x1p0_zvl32b1p0
> 
> So adding zve32x through the new Zv{b,k}* implication does not seem to 
> trigger
> the further dependencies normally implied by zve32x. This looks like it may
> come from the implicit-subset processing order / single forward scan.

So this comment

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

really is misleading. "in order" doesn't quite get it, as apparently only
forward references are permitted within the table. That then means that
the patch needs to move up the whole Zv{b,k} group as well.

Jan