riscv-collab / riscv-gnu-toolchain

GNU toolchain for RISC-V, including GCC
Other
3.51k stars 1.16k forks source link

How to build V extension? #1301

Closed qinzheng93 closed 1 year ago

qinzheng93 commented 1 year ago

Hi guys, for now (Aug 5th, 2023), what is the best practice to use RVV? Should I use rvv-next branch or just master branch? Should I configure with --with-arch=rv64gcv or --with-arch=rv64gc? And is there any documentation about this? Thank you.

TommyMurphyTM1234 commented 1 year ago

I think that upstream GCC 13.x has support for RISC-V vector extensions now. Since riscv-gnu-toolchain still uses GCC 12 and this PR still remains pending:

in order to use GCC 13 sources you need to do this:

git clone https://github.com/riscv-collab/riscv-gnu-toolchain
cd riscv-gnu-toolchain
git clone https://github.com/gcc-mirror/gcc -b releases/gcc-13 gcc-13
./configure --prefix=`pwd`/installed-tools --with-arch=rv64gcv --with-abi=lp64d --with-gcc-src=`pwd`/gcc-13
make

or maybe this to use the GCC 13.2 sources?

git clone https://github.com/riscv-collab/riscv-gnu-toolchain
cd riscv-gnu-toolchain
git clone https://github.com/gcc-mirror/gcc gcc-13
cd gcc-13
git checkout tags/releases/gcc-13.2.0 -b releases/gcc-13
cd ..
./configure --prefix=`pwd`/installed-tools --with-arch=rv64gcv --with-abi=lp64d --with-gcc-src=`pwd`/gcc-13
make

This should build a toolchain that supports rv64gcv/lp64d by default using the upstream GCC 13 sources but I haven't actually tried it myself yet.

Should I configure with --with-arch=rv64gcv or --with-arch=rv64gc?

If you want a toolchain that supports rv64gcv[/lp64d] by default and bundles standard live/startup code object modules for that arch then use the former. If you want rv64gc/[lp64d] support by default then use the latter - but then you'll also need to use configure ... --with-multilib-generator="rv64gcv-lp64d--" to also build multilibs for rv64gcv/lp64d. I'm assuming that you're building the bare-metal Newlib toolchain here. --with-multilib-generator doesn't work for the Linux toolchain and you have to tweak the default list of multilibs in t-linux-multilib for the Linux toolchain.

Note that the toolchain built as above for a default arch/abi of rv64gc/lp64d can still generate code for -march=rv64gcv -mabi=lp64d but will not link with startup code/standard libraries unless the toolchain is configured to generate multilibs for rv64gcv/lp64d. A RISC-V toolchain can always generate code for any implemented extensions but will fail to link with the multilibs/startup code for the relevant arch/abi if they're referenced but do not exist.

TommyMurphyTM1234 commented 1 year ago

Ah - the upstream support may "just" be for vector intrinsics:

RISC-V

and not also inferring vector extension use from code patterns. As such, it may be the case that you need to continue using the rvv-next branch as outlined here:

TommyMurphyTM1234 commented 1 year ago

As far as I can see:

So there doesn't seem to be much recent activity on the vector extensions development front - unless it's all done now and awaiting merging into the master branches of the above repos and then upstreaming to GCC?

Does anybody know what the status is?

TommyMurphyTM1234 commented 1 year ago

With regard to the original query, it does look like the correct way to build a vector extension enabled toolchain is still as follows:

git clone https://github.com/riscv-collab/riscv-gnu-toolchain -b rvv-next issue-1301
cd issue-1301

# Toolchain that supports rv64gcv/lp64d by default
./configure --prefix=`pwd`/installed-tools --with-arch=rv64gcv --with-abi=lp64d

OR

# Toolchain that supports rv64gc/lp64d by default and rv64gcv/lp64d via multilibs when -march=rv64gcv -mabi=lp64d specified at compile time
./configure --prefix=`pwd`/installed-tools --with-multilib-generator="rv64gcv-lp64d--"

make 2>&1 | tee build.log
qinzheng93 commented 1 year ago

With regard to the original query, it does look like the correct way to build a vector extension enabled toolchain is still as follows:

git clone https://github.com/riscv-collab/riscv-gnu-toolchain -b rvv-next issue-1301
cd issue-1301

# Toolchain that supports rv64gcv/lp64d by default
./configure --prefix=`pwd`/installed-tools --with-arch=rv64gcv --with-abi=lp64d

OR

# Toolchain that supports rv64gc/lp64d by default and rv64gcv/lp64d via multilibs when -march=rv64gcv -mabi=lp64d specified at compile time
./configure --prefix=`pwd`/installed-tools --with-multilib-generator="rv64gcv-lp64d--"

make 2>&1 | tee build.log

This does work. Thanks for your help.

BTW, the following arguments should be used with QEMU:

qemu-riscv64 -cpu rv64,v=true,zba=true,vlen=512,vext_spec=v1.0 ./main
TommyMurphyTM1234 commented 1 year ago
qemu-riscv64 -cpu rv64,v=true,zba=true,vlen=512,vext_spec=v1.0 ./main

Why zba=true? The toolchain that is built using my instructions above does not specify any bit-manipulation extensions in the arch/abi tuples specified at configuration time.

qinzheng93 commented 1 year ago
```shell
qemu-riscv64 -cpu rv64,v=true,zba=true,vlen=512,vext_spec=v1.0 ./main

Why zba=true? The toolchain that is built using my instructions above does not specify any bit-manipulation extensions in the arch/abi tuples specified at configuration time.

I just copy the arguments from another post. Omitting it still works. Thanks for noting this.

TommyMurphyTM1234 commented 1 year ago

Resolved.

joe-img commented 1 year ago

As far as I can see:

* https://github.com/riscv-collab/riscv-gnu-toolchain/tree/rvv-next: last commit 12th November 2022

* https://github.com/riscv-collab/riscv-gcc/tree/riscv-gcc-rvv-next: last commit 16th March 2023

So there doesn't seem to be much recent activity on the vector extensions development front - unless it's all done now and awaiting merging into the master branches of the above repos and then upstreaming to GCC?

Does anybody know what the status is?

I think all RISC-V gcc vector dev is done on master now. There is also a riscv vendor branch which seems to be latest gcc release + riscv (mainly vector) good stuff. Commands to setup in git:

$ git config --add remote.origin.fetch "+refs/vendors/riscv/heads/*:refs/remotes/origin/riscv/*"
$ git config --add remote.origin.fetch "+refs/vendors/riscv/tags/*:refs/tags/riscv/*"
TommyMurphyTM1234 commented 1 year ago

As far as I can see:

* https://github.com/riscv-collab/riscv-gnu-toolchain/tree/rvv-next: last commit 12th November 2022

* https://github.com/riscv-collab/riscv-gcc/tree/riscv-gcc-rvv-next: last commit 16th March 2023

So there doesn't seem to be much recent activity on the vector extensions development front - unless it's all done now and awaiting merging into the master branches of the above repos and then upstreaming to GCC? Does anybody know what the status is?

I think all RISC-V gcc vector dev is done on master now. There is also a riscv vendor branch which seems to be latest gcc release + riscv (mainly vector) good stuff. Commands to setup in git:

$ git config --add remote.origin.fetch "+refs/vendors/riscv/heads/*:refs/remotes/origin/riscv/*"
$ git config --add remote.origin.fetch "+refs/vendors/riscv/tags/*:refs/tags/riscv/*"

Thanks @joe-img. So is the correct way to build the latest vector enabled toolchain this:

git clone https://github.com/riscv-collab/riscv-gnu-toolchain
cd issue-1301
./configure --prefix=`pwd`/installed-tools --with-multilib-generator="rv64gcv-lp64d--"
make 2>&1 | tee build.log

or this:

git clone https://github.com/riscv-collab/riscv-gnu-toolchain -b rvv-next issue-1301
cd issue-1301
./configure --prefix=`pwd`/installed-tools --with-multilib-generator="rv64gcv-lp64d--"
make 2>&1 | tee build.log

or something else using this:

git config --add remote.origin.fetch "+refs/vendors/riscv/heads/*:refs/remotes/origin/riscv/*"
git config --add remote.origin.fetch "+refs/vendors/riscv/tags/*:refs/tags/riscv/*"

If it's the latter can you or somebody else outline the full set of commands required please? Thanks.

joe-img commented 1 year ago

Thanks @joe-img. So is the correct way to build the latest vector enabled toolchain this:

By the looks of it, the rvv-next branch is stale, and probably shouldn't be used.

I suppose it depends on what you meant by 'latest'. The way I see it is you have three options: 1) Latest GCC 13.1 release. Only vector intrinsic support, no autovectorization. Most stable. 2) Current GCC master. Most riscv autovectorization support. Least stable. 3) Vendor branch riscv/gcc-13-with-riscv-opts. Should have most if not all the autovectorization support that master does. Should be more stable than gcc master due to the commits being cherry-picked on top of a release branch.

IMO option 3 is a good compromise.

This is how I would do it: (commands untested)

git clone --recursive https://github.com/riscv-collab/riscv-gnu-toolchain
cd riscv-gnu-toolchain/gcc
git remote add origin https://gcc.gnu.org/git/gcc.git
git config --add remote.origin.fetch "+refs/vendors/riscv/heads/*:refs/remotes/origin/riscv/*"
git config --add remote.origin.fetch "+refs/vendors/riscv/tags/*:refs/tags/riscv/*"
git fetch origin
git checkout origin/riscv/gcc-13-with-riscv-opts
cd ..
./configure --prefix=/path/to/install-dir --with-multilib-generator="rv64gcv-lp64d--" --with-arch rv64gcv --with-abi lp64d
wanghuibin0 commented 1 year ago

why not use riscv64-*-llvm? It has supported auto vectorization and generate rvv instructions.

joe-img commented 1 year ago

why not use riscv64-*-llvm? It has supported auto vectorization and generate rvv instructions.

You're not wrong. The autovectorization in clang is broadly much better. I think this is beside the point though, this is the gnu toolchain repo and it's reasonable to assume the question applies to just the gnu tools.

TommyMurphyTM1234 commented 1 year ago

Thanks @joe-img. So is the correct way to build the latest vector enabled toolchain this:

By the looks of it, the rvv-next branch is stale, and probably shouldn't be used.

I suppose it depends on what you meant by 'latest'. The way I see it is you have three options:

  1. Latest GCC 13.1 release. Only vector intrinsic support, no autovectorization. Most stable.
  2. Current GCC master. Most riscv autovectorization support. Least stable.
  3. Vendor branch riscv/gcc-13-with-riscv-opts. Should have most if not all the autovectorization support that master does. Should be more stable than gcc master due to the commits being cherry-picked on top of a release branch.

IMO option 3 is a good compromise.

This is how I would do it: (commands untested)

git clone --recursive https://github.com/riscv-collab/riscv-gnu-toolchain
cd riscv-gnu-toolchain/gcc
git remote add origin https://gcc.gnu.org/git/gcc.git
git config --add remote.origin.fetch "+refs/vendors/riscv/heads/*:refs/remotes/origin/riscv/*"
git config --add remote.origin.fetch "+refs/vendors/riscv/tags/*:refs/tags/riscv/*"
git fetch origin
git checkout origin/riscv/gcc-13-with-riscv-opts
cd ..
./configure --prefix=/path/to/install-dir --with-multilib-generator="rv64gcv-lp64d--" --with-arch rv64gcv --with-abi lp64d

Thanks a lot @joe-img - that's very useful info. Much appreciated.

Just a couple of small things here:

./configure --prefix=/path/to/install-dir --with-multilib-generator="rv64gcv-lp64d--" --with-arch rv64gcv --with-abi lp64d

--with-multilib-generator="rv64gcv-lp64d--" is unnecessary here since the toolchain is configured to support rv64gcv/lp64d by default so the libs/startup objects for that arch/abi will be built automatically.

Also, it should be --with-arch=rv64gcv --with-abi=lp64d as far as I know.

TommyMurphyTM1234 commented 1 year ago

why not use riscv64-*-llvm? It has supported auto vectorization and generate rvv instructions.

That's an option too but the original query was about the GCC toolchain.

I think this is beside the point though, this is the gnu toolchain repo and it's reasonable to assume the question applies to just the gnu tools.

Well, with recent changes this repo actually caters for building both GCC and LLVM based toolchains.

wanghuibin0 commented 1 year ago

why not use riscv64-*-llvm? It has supported auto vectorization and generate rvv instructions.

You're not wrong. The autovectorization in clang is broadly much better. I think this is beside the point though, this is the gnu toolchain repo and it's reasonable to assume the question applies to just the gnu tools.

Thanks for reply. I am wondering what the relationship of the llvm package in the release page with this repo is ...

TommyMurphyTM1234 commented 1 year ago

why not use riscv64-*-llvm? It has supported auto vectorization and generate rvv instructions.

You're not wrong. The autovectorization in clang is broadly much better. I think this is beside the point though, this is the gnu toolchain repo and it's reasonable to assume the question applies to just the gnu tools.

Thanks for reply. I am wondering what the relationship of the llvm package in the release page with this repo is ...

See my previous post. The ability to build a GCC or LLVM toolchain using this repo was added recently. Before that GCC was the only option.

TommyMurphyTM1234 commented 1 year ago

This is how I would do it: (commands untested)

git clone --recursive https://github.com/riscv-collab/riscv-gnu-toolchain
cd riscv-gnu-toolchain/gcc
git remote add origin https://gcc.gnu.org/git/gcc.git
git config --add remote.origin.fetch "+refs/vendors/riscv/heads/*:refs/remotes/origin/riscv/*"
git config --add remote.origin.fetch "+refs/vendors/riscv/tags/*:refs/tags/riscv/*"
git fetch origin
git checkout origin/riscv/gcc-13-with-riscv-opts
cd ..
./configure --prefix=/path/to/install-dir --with-multilib-generator="rv64gcv-lp64d--" --with-arch rv64gcv --with-abi lp64d

FWIW I tried those instructions and they work - the only minor issue is that this seems redundant given the error generated:

git remote add origin https://gcc.gnu.org/git/gcc.git
fatal: remote origin already exists.
joe-img commented 1 year ago

the only minor issue is that this seems redundant given the error generated

Fair point. I did forget the submodules would already have that remote. Thanks for checking :)

qinzheng93 commented 1 year ago

Thanks @joe-img. So is the correct way to build the latest vector enabled toolchain this:

By the looks of it, the rvv-next branch is stale, and probably shouldn't be used.

I suppose it depends on what you meant by 'latest'. The way I see it is you have three options:

  1. Latest GCC 13.1 release. Only vector intrinsic support, no autovectorization. Most stable.
  2. Current GCC master. Most riscv autovectorization support. Least stable.
  3. Vendor branch riscv/gcc-13-with-riscv-opts. Should have most if not all the autovectorization support that master does. Should be more stable than gcc master due to the commits being cherry-picked on top of a release branch.

IMO option 3 is a good compromise.

This is how I would do it: (commands untested)

git clone --recursive https://github.com/riscv-collab/riscv-gnu-toolchain
cd riscv-gnu-toolchain/gcc
git remote add origin https://gcc.gnu.org/git/gcc.git
git config --add remote.origin.fetch "+refs/vendors/riscv/heads/*:refs/remotes/origin/riscv/*"
git config --add remote.origin.fetch "+refs/vendors/riscv/tags/*:refs/tags/riscv/*"
git fetch origin
git checkout origin/riscv/gcc-13-with-riscv-opts
cd ..
./configure --prefix=/path/to/install-dir --with-multilib-generator="rv64gcv-lp64d--" --with-arch rv64gcv --with-abi lp64d

I use the commands above to build gcc, but the resultant gcc cannot find rvv functions such as "vfmacc_vf_f32m1" or rvv types such as "vfloat16m1_t". How should I fix this?

joe-img commented 1 year ago

I use the commands above to build gcc, but the resultant gcc cannot find rvv functions such as "vfmacc_vf_f32m1" or rvv types such as "vfloat16m1_t". How should I fix this?

All riscv vector intrinsics are prepended by __riscv_, so it should be __riscv_vfmacc_vf_f32m1 See https://github.com/riscv-non-isa/rvv-intrinsic-doc

qinzheng93 commented 1 year ago

All riscv vector intrinsics are prepended by __riscv_, so it should be __riscv_vfmacc_vf_f32m1 See https://github.com/riscv-non-isa/rvv-intrinsic-doc

Thanks, it does works for __riscv_vfmacc_vf_f32m1. But I still cannot find vfloat16m1_t.

Floating-point types with element widths of 16 requires the zvfh and zvfhmin extension to be specified in the architecture.

I also notice that in the spec the element width of 16 requires zvfh and zvfhmin extension. I don't know how I should build the toolchains to enable these extensions.

joe-img commented 1 year ago

All riscv vector intrinsics are prepended by __riscv_, so it should be __riscv_vfmacc_vf_f32m1 See https://github.com/riscv-non-isa/rvv-intrinsic-doc

Thanks, it does works for __riscv_vfmacc_vf_f32m1. But I still cannot find vfloat16m1_t.

Floating-point types with element widths of 16 requires the zvfh and zvfhmin extension to be specified in the architecture.

I also notice that in the spec the element width of 16 requires zvfh and zvfhmin extension. I don't know how I should build the toolchains to enable these extensions.

You don't have to build it in a special way, it will already have the extensions. As with any extension, you need to add it your arch string, e.g. rv64gcv_zvfhmin

qinzheng93 commented 1 year ago

You don't have to build it in a special way, it will already have the extensions. As with any extension, you need to add it your arch string, e.g. rv64gcv_zvfhmin

I build the following code with -march=rv64gcv_zfh:

#include <riscv_vector.h>
int main() {
  vfloat16m1_t _s, _w;
  _Float16 _v;
  size_t vl;
  _s = __riscv_vfmacc_vf_f16m1(_s, _v, _w, vl);
  return 0;
}

and got the following errors:

$ riscv64-unknown-linux-gnu-g++ -march=rv64gcv_zfh rvv_test_zfh.cc -o rvv_test_zfh
rvv_test_zfh.cc: In function 'int main()':
rvv_test_zfh.cc:4:3: error: 'vfloat16m1_t' was not declared in this scope; did you mean 'vfloat64m1_t'?
    4 |   vfloat16m1_t _s, _w;
      |   ^~~~~~~~~~~~
      |   vfloat64m1_t
rvv_test_zfh.cc:7:3: error: '_s' was not declared in this scope; did you mean '_v'?
    7 |   _s = __riscv_vfmacc_vf_f16m1(_s, _v, _w, vl);
      |   ^~
      |   _v
rvv_test_zfh.cc:7:40: error: '_w' was not declared in this scope; did you mean '_v'?
    7 |   _s = __riscv_vfmacc_vf_f16m1(_s, _v, _w, vl);
      |                                        ^~
      |                                        _v
rvv_test_zfh.cc:7:8: error: '__riscv_vfmacc_vf_f16m1' was not declared in this scope; did you mean '__riscv_vfmacc_vf_f64m1'?
    7 |   _s = __riscv_vfmacc_vf_f16m1(_s, _v, _w, vl);
      |        ^~~~~~~~~~~~~~~~~~~~~~~
      |        __riscv_vfmacc_vf_f64m1

and got the following errors with -march=rv64gcv_zvfhmin:

rvv_test_zfh.cc: In function 'int main()':
rvv_test_zfh.cc:9:1: error: unrecognizable insn:
    9 | }
      | ^
(insn 39 38 40 2 (set (reg:RVVM1HF 161)
        (if_then_else:RVVM1HF (unspec:RVVMF16BI [
                    (const_vector:RVVMF16BI repeat [
                            (const_int 1 [0x1])
                        ])
                    (reg:DI 165)
                    (const_int 2 [0x2]) repeated x2
                    (const_int 0 [0]) repeated x2
                    (reg:SI 66 vl)
                    (reg:SI 67 vtype)
                    (reg:SI 69 frm)
                ] UNSPEC_VPREDICATE)
            (plus:RVVM1HF (mult:RVVM1HF (vec_duplicate:RVVM1HF (reg:HF 162))
                    (reg:RVVM1HF 163))
                (reg:RVVM1HF 164))
            (reg:RVVM1HF 164))) "rvv_test_zfh.cc":7:31 -1
     (nil))
during RTL pass: vregs
rvv_test_zfh.cc:9:1: internal compiler error: in extract_insn, at recog.cc:2791
0x76e345 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
        ../.././gcc/gcc/rtl-error.cc:108
0x76e367 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        ../.././gcc/gcc/rtl-error.cc:116
0x76d82e extract_insn(rtx_insn*)
        ../.././gcc/gcc/recog.cc:2791
0xbba8fd instantiate_virtual_regs_in_insn
        ../.././gcc/gcc/function.cc:1611
0xbba8fd instantiate_virtual_regs
        ../.././gcc/gcc/function.cc:1985
0xbba8fd execute
        ../.././gcc/gcc/function.cc:2034
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

What should I do then to fix this?

pz9115 commented 1 year ago

I think it not supported yet.

qinzheng93 commented 1 year ago

I think it not supported yet.

So if Zfh is correctly supported, vfloat16m1_t and fp16 arithmetics should be available, right?

pz9115 commented 1 year ago

I think it not supported yet.

So if Zfh is correctly supported, vfloat16m1_t and fp16 arithmetics should be available, right?

Sorry, I tried again and use 'zvfh' then it worked, so it seems should use 'zvfh' instead of 'zfh' , here is the link @qinzheng93 : https://godbolt.org/z/xcrr8TT94

qinzheng93 commented 1 year ago

Sorry, I tried again and use 'zvfh' then it worked, so it seems should use 'zvfh' instead of 'zfh' , here is the link @qinzheng93 : https://godbolt.org/z/xcrr8TT94

Thanks @pz9115 , I successfully generate assembled code with rv64gcv_zvfh (with -S), but I cannot generate the binaries. The errors are:

Assembler messages:
Error: rv64imafdcv_zicsr_zifencei_zfhmin_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvl128b_zvl32b_zvl64b: unknown prefixed ISA extension `zvfh'
/tmp/ccftN2pF.s:3: Error: rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_v1p0_zicsr2p0_zifencei2p0_zfhmin1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvfh1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0: unknown prefixed ISA extension `zvfh'
pz9115 commented 1 year ago

I remeber that Tsukasa had update this in binutils, maybe you should try update your binutils repo. Use

cd binutils
git fetch origin
git pull origin master

Hope this helps.

TommyMurphyTM1234 commented 1 year ago

I remeber that Tsukasa had update this in binutils

This perhaps?

Edit: ignore the above and see here instead:

@qinzheng93 - can you clarify exactly how you are building the toolchain (all commands used), how you are invoking it (in particular what -march=... -mabi=... options) and provide a small self-contained reproducible test program that illustrates any issues that you are having? Thanks.

qinzheng93 commented 1 year ago

I build the toolchain with the following command:

git clone https://github.com/riscv-collab/riscv-gnu-toolchain
cd riscv-gnu-toolchain/gcc
git remote add origin https://gcc.gnu.org/git/gcc.git
git config --add remote.origin.fetch "+refs/vendors/riscv/heads/*:refs/remotes/origin/riscv/*"
git config --add remote.origin.fetch "+refs/vendors/riscv/tags/*:refs/tags/riscv/*"
git fetch origin
git checkout origin/riscv/gcc-13-with-riscv-opts
cd ..
./configure --prefix=/path/to/install-dir --with-arch=rv64gcv --with-abi=lp64d
make linux

The testing code is:

#include <riscv_vector.h>
int main() {
  vfloat16m1_t _s, _w;
  _Float16 _v;
  size_t vl;
  _s = __riscv_vfmacc_vf_f16m1(_s, _v, _w, vl);
  return 0;
}

And the compilation command is:

riscv64-unknown-linux-gnu-g++ -march=rv64gcv_zvfh -mabi=lp64d rvv_test.cc -o rvv_test

The error message is:

Assembler messages:
Error: rv64imafdcv_zicsr_zifencei_zfhmin_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvl128b_zvl32b_zvl64b: unknown prefixed ISA extension `zvfh'
/tmp/ccd7hpj7.s:3: Error: rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_v1p0_zicsr2p0_zifencei2p0_zfhmin1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvfh1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0: unknown prefixed ISA extension `zvfh'
pz9115 commented 1 year ago

It's the recently work in binutils upstream:

https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e57ed3695a65ecbc76c195ad0535657150b7d5d9

So you should update your binutils repo then try to build again.

TommyMurphyTM1234 commented 1 year ago

I tried building the toolchain as follows:

git clone https://github.com/riscv-collab/riscv-gnu-toolchain
cd riscv-gnu-toolchain/gcc
# The following is unnecessary and generates an error
# See: https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1301#issuecomment-1671292533
# git remote add origin https://gcc.gnu.org/git/gcc.git
git config --add remote.origin.fetch "+refs/vendors/riscv/heads/*:refs/remotes/origin/riscv/*"
git config --add remote.origin.fetch "+refs/vendors/riscv/tags/*:refs/tags/riscv/*"
git fetch origin
git checkout origin/riscv/gcc-13-with-riscv-opts
cd ..
# See: https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1301#issuecomment-1677086925
cd binutils
git fetch origin
# Have to set these two or the next command errors out
git config --global user.email "tommy_murphy@hotmail.com"
git config --global user.name "Tommy Murphy"
git pull origin master

But the last command tells me that there are dozens of conflicts and finishes with:

Automatic merge failed; fix conflicts and then commit the result.

See here: conflicts.log

joe-img commented 1 year ago

But the last command tells me that there are dozens of conflicts and finishes with:

Try not doing git pull, rather just git checkout origin/master

qinzheng93 commented 1 year ago

Try not doing git pull, rather just git checkout origin/master

Great! It works well now. BYW, I have also tried the latest GCC-13.2.0 but it seems to have no zvfh support.

TommyMurphyTM1234 commented 1 year ago

Try not doing git pull, rather just git checkout origin/master

Great! It works well now. BYW, I have also tried the latest GCC-13.2.0 but it seems to have no zvfh support.

I presume you mean that neither 13.1.0 nor 13.2.0 have support for zvfh?

qinzheng93 commented 1 year ago

I presume you mean that neither 13.1.0 nor 13.2.0 have support for zvfh?

I haven't tested the releases/gcc-13.1.0 branch. But releases/gcc-13.2.0 does not have zvfh support. Neither vfloat16m1_t nor __riscv_vfmacc_vf_f16m1 can be found when compiled with -march=rv64gcv_zvfh.

The vendor branch riscv/gcc-13-with-riscv-opts does have zvfh support.