For most CPU types out there, ./configure normalizes all
variations into base form plus, optionally, variations,
to find the proper arch-specific code.  In particular,
it's possible to use
   ./configure --cpu=$(uname -m)
and it will figure out the right base cpu family out of
that. But this does not work for riscv64 for example,
since there's no similar normalisation for that one.

For now, as far as I can see, there'no support for other
riscv "sizes" (like riscv32 which actually esists as
hardware). So for the time being, just normalize the
cpu name to be "riscv" for all riscv* variants, just
like it is done for arm and mips.  If/when support for
other riscv variants will be added, this might be
extended to distinguish them based on __LP64__ define
or __riscv_xlen==32/64/128.

Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
---
 configure | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configure b/configure
index 9e407ce2e3..1deb65c95f 100755
--- a/configure
+++ b/configure
@@ -578,6 +578,9 @@ case "$cpu" in
     cpu="ppc64"
     CPU_CFLAGS="-m64 -mlittle-endian" ;;
 
+  riscv*)
+    cpu="riscv" ;;
+
   s390)
     CPU_CFLAGS="-m31" ;;
   s390x)
-- 
2.30.2

On Sat, 4 Feb 2023 at 11:26, Michael Tokarev <mjt@tls.msk.ru> wrote:
>
> For most CPU types out there, ./configure normalizes all
> variations into base form plus, optionally, variations,
> to find the proper arch-specific code.  In particular,
> it's possible to use
>    ./configure --cpu=$(uname -m)
> and it will figure out the right base cpu family out of
> that. But this does not work for riscv64 for example,
> since there's no similar normalisation for that one.

I don't think that's something we should be encouraging
users to do. The most common case should be "configure
correctly detects the host CPU type by probing the
compiler #defines, and the user does not need to specify".
The next most common thing should be "the user has some
special-case need to override this, and they know what
they want, and they specify the right value, in this
case "riscv".

We've put in some work to get configure away from its
old habit of falling back to "guess based on uname -m",
but that default code path is for the moment still there,
and so the "canonicalize host CPU name" code also is
still present, for:
 (1) the cases when you get into that default fallback
 (2) backwards-compatibility with users who are already
     passing --cpu=armv4l or whatever

But I don't think we should expand this legacy code
and encourage users to pass more odd stuff to --cpu.

We could probably deprecate-and-drop some of the
canonicalization handling for other host architectures.

thanks
-- PMM

04.02.2023 18:05, Peter Maydell пишет:
> On Sat, 4 Feb 2023 at 11:26, Michael Tokarev <mjt@tls.msk.ru> wrote:
>>
>> For most CPU types out there, ./configure normalizes all
>> variations into base form plus, optionally, variations,
>> to find the proper arch-specific code.  In particular,
>> it's possible to use
>>     ./configure --cpu=$(uname -m)
>> and it will figure out the right base cpu family out of
>> that. But this does not work for riscv64 for example,
>> since there's no similar normalisation for that one.
> 
> I don't think that's something we should be encouraging
> users to do. The most common case should be "configure
> correctly detects the host CPU type by probing the
> compiler #defines, and the user does not need to specify".
> The next most common thing should be "the user has some
> special-case need to override this, and they know what
> they want, and they specify the right value, in this
> case "riscv".
...

This all makes perfect sense, thank you Peter for explaining.

I already told the original reporter (on IRC) that it looks
like what they're doing is wrong, just using proper CC (or
--cross-prefix) should DTRT, and it turned out they don't
even remember anymore why they've put this --cpu= there.

The current code in ./configure just looked incomplete to
me, so I went on and sent a patch to make it more, in my
view, uniform.

It is for the better that it is not needed.

/mjt