On Wed, 26 Jun 2024 08:50:57 PDT (-0700), Andrea Parri wrote:
Tested using amo.exp with rv64gc_zalrsc, rv64id_zaamo, rv64id_zalrsc,
rv64id_zabha (using tip-of-tree qemu w/ zabha patches [2] applied for
execution tests).
My interpretation of the Zabha specification, in particular of "The Zabha
extension depends upon the Zaamo standard extension", is that rv64id_zabha
should result in a dependency violation (some compiler warning).
The changes at stake seem instead to make the Zabha extension "select" the
Zaamo extension; IOW, these changes seem to make rv64id_zabha an alias of
rv64id_zaamo_zabha: I am wondering whether this was intentional?
I think your interpretation of "depends on" is reasonable, but it's not
the way we've handled it for other extension dependencies. For the
others we're treating "depends on" the way this code does, ie enabling
the dependant extensions implicitly. IIRC that's how the RISC-V specs
want it to be.
That said, we do call it "implied" in the sources because that's really
the right word for it. So we should probably add something to the docs
that describes how/why things are this way, as I don't think it's the
first time someone's been confused.
Maybe just something like
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 23d90db2925..429275d56df 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -31037,6 +31037,10 @@ If both @option{-march} and @option{-mcpu=} are not
specified, the default for
this argument is system dependent, users who want a specific architecture
extensions should specify one explicitly.
+When the RISC-V specifications define an extension as depending on other
+extensions, GCC will implicitly add the dependant extensions to the enabled
+extension set if they weren't added explicitly.
+
@opindex mcpu
@item -mcpu=@var{processor-string}
Use architecture of and optimize the output for the given processor, specified
would do it?
Andrea
