Closed qinzheng93 closed 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.
Ah - the upstream support may "just" be for vector intrinsics:
RISC-V
- Support for vector intrinsics as specified in version 0.11 of the RISC-V vector intrinsic specification, thanks Ju-Zhe Zhong from RiVAI for contributing most of implementation.
- ...
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:
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?
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
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
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.
```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.
Resolved.
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/*"
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.
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
why not use riscv64-*-llvm? It has supported auto vectorization and generate rvv instructions.
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 @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:
- Latest GCC 13.1 release. Only vector intrinsic support, no autovectorization. Most stable.
- Current GCC master. Most riscv autovectorization support. Least stable.
- 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.
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.
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 ...
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.
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.
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 :)
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:
- Latest GCC 13.1 release. Only vector intrinsic support, no autovectorization. Most stable.
- Current GCC master. Most riscv autovectorization support. Least stable.
- 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?
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
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.
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-docThanks, it does works for
__riscv_vfmacc_vf_f32m1
. But I still cannot findvfloat16m1_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
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?
I think it not supported yet.
I think it not supported yet.
So if Zfh is correctly supported, vfloat16m1_t
and fp16 arithmetics should be available, right?
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
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'
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.
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.
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'
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.
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
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
Try not doing
git pull
, rather justgit 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.
Try not doing
git pull
, rather justgit 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
?
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.
Hi guys, for now (Aug 5th, 2023), what is the best practice to use RVV? Should I use
rvv-next
branch or justmaster
branch? Should I configure with--with-arch=rv64gcv
or--with-arch=rv64gc
? And is there any documentation about this? Thank you.