RFR: 8368950: RISC-V: fail to catch out of order declarations among dependent cpu extensions/flags [v2]

[Fei Yang]

On Tue, 14 Oct 2025 12:50:06 GMT, Hamlin Li <mli at openjdk.org> wrote:

> > Thanks for the quick update. This reminds me of the order in which we enable these ISA features in `RiscvHwprobe::add_features_from_query_result`. In your previous PR #27562, we reorder the declarations. But we should sync `RiscvHwprobe::add_features_from_query_result` with that new order at the same time, right?
> 
> Not sure if I understand you correctly.
> 
> I think it's not necessary to do so, take `v` and `zvfh` as example, if in `RiscvHwprobe::add_features_from_query_result`, `zvfh` is enabled detected and enabled before `v`, and `v` is disabled by hw probe, then in the while loop of `VM_Version::setup_cpu_available_features`, `zvfh` will still be diabled because of `v` disabling. So the order in the`RiscvHwprobe::add_features_from_query_result` will not affect the correctness of dependency check.
> 
> Or do you mean we should keep the same order of extensions and non-extensions in `RiscvHwprobe::add_features_from_query_result` as in `RV_EXT_FEATURE_FLAGS` and `RV_NON_EXT_FEATURE_FLAGS` for readability or some other reasons? I can also do it in this pr, just note it's not necessary to do so. :)

Here is what I am thinking: Your `verify_deps` only ensures that the declarations of the extensions are in the correct order (as indicated by the `_cpu_feature_index`). And that is the order in which we should follow when enabling these extensions. So for this to work, the order should be refected by `RiscvHwprobe::add_features_from_query_result` which does the work. For safety, I think we should always sync them. Make sense?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27572#issuecomment-3402077819