From my personal perspective, I am more inclined to use the riscv64 prefix.

In fact, we are currently compiling using the rv64gc extension, which is the default option for riscv64-linux-gnu-gcc. Therefore, the choice of prefix is merely a nominal distinction without any substantive difference.

Most software, such as GCC, uname -m, LLVM, Golang, and notably Python itself, use riscv64 as their prefix. This is due to the following two reasons:

All Linux distributions (Ubuntu, Debian, Fedora, Arch Linux, etc.) use rv64gc as their baseline. Hence, software running on riscv64 Linux can assume that the GC extension is available.
GC is just an instruction set extension. Just as we might compile with -march=avx2 on x86, we don't refer to it as x86_64-avx2-linux, do we?

Rust is a unique case, as it uses the riscv64gc prefix for its target. Honestly, I can't think of another example.

This design choice in Rust has been a source of considerable frustration. Many software developed with Rust have to determine whether to call the riscv64 prefix GCC if the current target is riscv64gc prefix, or vice versa.

I am not an expert on uv, so I don't know why uv uses the riscv64gc prefix. However, I suspect that uv uses the same target as Rust. In that case, I believe a better approach would be to follow the practice of other software and make a special case to use the riscv64 prefix.

Uh oh!

Consider tagging as riscv64gc instead of riscv64 #504

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Consider tagging as `riscv64gc` instead of `riscv64` #504