brucehoult

riscv-gnu-toolchain

C2023–2023

brucehoult / riscv-gnu-toolchain

riscv-gnu-toolchain

GNU toolchain for RISC-V, including GCC

Hardware & Embedded

Explore on GitHub Read Hacker News discussions

3Distinct people

5Mentions

0Explicit recommenders

14GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

GNU toolchain for RISC-V, including GCC

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by week5 dated mentions

Observed mentions: 2023-05-20 21:31:46 UTC to 2023-11-11 18:35:09 UTC. Weeks start Monday, UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
May 15	2023-05-15 00:00:00 UTC	2023-05-22 00:00:00 UTC	1	1
May 22	2023-05-22 00:00:00 UTC	2023-05-29 00:00:00 UTC	0	0
May 29	2023-05-29 00:00:00 UTC	2023-06-05 00:00:00 UTC	0	0
Jun 5	2023-06-05 00:00:00 UTC	2023-06-12 00:00:00 UTC	0	0
Jun 12	2023-06-12 00:00:00 UTC	2023-06-19 00:00:00 UTC	0	0
Jun 19	2023-06-19 00:00:00 UTC	2023-06-26 00:00:00 UTC	0	0
Jun 26	2023-06-26 00:00:00 UTC	2023-07-03 00:00:00 UTC	0	0
Jul 3	2023-07-03 00:00:00 UTC	2023-07-10 00:00:00 UTC	0	0
Jul 10	2023-07-10 00:00:00 UTC	2023-07-17 00:00:00 UTC	0	0
Jul 17	2023-07-17 00:00:00 UTC	2023-07-24 00:00:00 UTC	0	0
Jul 24	2023-07-24 00:00:00 UTC	2023-07-31 00:00:00 UTC	1	1
Jul 31	2023-07-31 00:00:00 UTC	2023-08-07 00:00:00 UTC	0	0
Aug 7	2023-08-07 00:00:00 UTC	2023-08-14 00:00:00 UTC	0	0
Aug 14	2023-08-14 00:00:00 UTC	2023-08-21 00:00:00 UTC	1	1
Aug 21	2023-08-21 00:00:00 UTC	2023-08-28 00:00:00 UTC	0	0
Aug 28	2023-08-28 00:00:00 UTC	2023-09-04 00:00:00 UTC	0	0
Sep 4	2023-09-04 00:00:00 UTC	2023-09-11 00:00:00 UTC	0	0
Sep 11	2023-09-11 00:00:00 UTC	2023-09-18 00:00:00 UTC	0	0
Sep 18	2023-09-18 00:00:00 UTC	2023-09-25 00:00:00 UTC	0	0
Sep 25	2023-09-25 00:00:00 UTC	2023-10-02 00:00:00 UTC	0	0
Oct 2	2023-10-02 00:00:00 UTC	2023-10-09 00:00:00 UTC	0	0
Oct 9	2023-10-09 00:00:00 UTC	2023-10-16 00:00:00 UTC	0	0
Oct 16	2023-10-16 00:00:00 UTC	2023-10-23 00:00:00 UTC	0	0
Oct 23	2023-10-23 00:00:00 UTC	2023-10-30 00:00:00 UTC	0	0
Oct 30	2023-10-30 00:00:00 UTC	2023-11-06 00:00:00 UTC	0	0
Nov 6	2023-11-06 00:00:00 UTC	2023-11-13 00:00:00 UTC	2	2

What Hacker News says

5 sources

brucehoult·Nov 11, 2023

That shouldn't be news. Other than the CanMV-K230 (Kendryte K230, single 1.6 GHz C908 core implementing RVV) which just started shipping in the last two weeks, every RISC-V board with RVV has either C906 or C910 cores which implement draft 0.7.1. Those CPU cores were announced in mid 2019 (when RVV 0.7.1 was the current draft) and boards using them start arriving in mid to late 2021. RVV 1.0 boards will start arriving in force next year, probably starting with the StarFive JH8110 SoC, and (apparently, though I'm not sure I believe it) an update of the SG2042 in the Pioneer, and also the 16 core (but faster cores) SG2380. > Do you happen to have the name of the gcc branch The branch has been deleted from the official repo. I have a snapshot on my github: https://github.com/brucehoult/riscv-gnu-toolchain Note that it is primarily binutils w

Read the rest

hich understands RVV 0.7.1. GCC understands it only to the extent of accepting "v" in "-march" and passing the right flags to the assembler. This enables using the gcc driver to build .s files and inline RVV asm in C. There is no support for RVV intrinsic functions or auto-vectorisation. It's also a somewhat old gcc. I use it to build .o files from assembly language, and then link them with C compiled by a newer gcc or llvm. Or not, most of the time gcc 9 is fine. THead have RVV 0.7.1 support in newer gcc, but I haven't been tracking that closely.

In RISC-V Vector benchmark results

camel-cdr·Nov 11, 2023

I've been using the one archived by bruce hoult: https://github.com/brucehoult/riscv-gnu-toolchain It doesn't support autovectorization though. Together with some assembly macros to allow writing in a subset of rvv 1.0 that also works on rvv 0.7.1 (source compatible, but not binary compatible. [0] There is also the xuantie toolchain that does support intrinsic and some sort of autovectorization, I think. But I haven't used that one, and it won't be as good as upstream gcc/llvm. [1] [0] https://github.com/camel-cdr/rvv-bench/blob/main/thirdparty/... [1] https://github.com/T-head-Semi/xuantie-gnu-toolchain

In RISC-V Vector benchmark results

brucehoult·Aug 20, 2023

TH1520 (Lichee Pi 4A, OoO cores similar to Arm A72) beats JH7110 (VisionFive 2 and others, in-order cores similar to Arm A55) on all micro-benchmarks. e.g. by about 40% on my branchy primes benchmark, which exercises the CPU and L1 cache only: https://hoult.org/primes.txt 10.430 sec Sipeed LM4A TH1520 4x C910 @1.848 GHz 216 bytes 19.3 billion clocks 10.851 sec Sophon SG2042 64x C910 RV64 @1.8? GHz 216 bytes 19.3 billion clocks 12.115 sec Pi4 Cortex A72 @ 1.5 GHz A64 300 bytes 18.2 billion clocks 14.885 sec VisionFive 2 U74 _zba_zbb @ 1.5 GHz 214 bytes 22.3 billion clocks 19.500 sec Odroid C2 A53 @ 1.536 GHz A64 276 bytes 30.0 billion clocks The TH1520 has much faster memcpy speeds at every level of cache and DRAM. https://hoult.org/JH7110_memcpy.txt https://hoult.org/JH7110_memcpy.txt And yet .

Read the rest

.. both Richard Jones at Fedora and I have found that the VisionFive 2 is actually slightly faster at building software packages! My result was that building the same binutils + gcc + newlib snapshot (an old one with RVV 0.7.1 support)... https://github.com/brucehoult/riscv-gnu-toolchain ... the VisionFive 2 takes 108 minutes while the Lichee Pi 4A takes 122 minutes. That's with the supplied fan on the LPi4A (and confirmed it's not throttling) and no cooling at all on the VisionFive 2. I used the same Samsung external USB3 SSD on both -- the VisionFive 2 gets slightly faster transfer speeds (IIRC 190 MB/s vs 160) with that, but that's not enough to matter: just 12s difference on the time to tar up the source directory, compared to a 14 minute build time difference. Both have enough RAM to cache everything anyway. > VF2 GPU: IMG BXE-4-32 Lichee Pi: ?? Anyone? BXM-4-64

In Lichee Pi 4A: Serious RISC-V Desktop Computing [video]

brucehoult·Jul 26, 2023

I've also found the 1.5 GHz in-order VF2 does remarkably well vs the 1.85 GHz OoO LPi4A on software build tasks, though not as extreme as Richard shows. I'm lazy and using the original Image-55 on my 8 GB VF2, and the Debian that came preloaded in the eMMC on the LPi4A. My mass-production LPi4A arrived yesterday, I haven't tried it yet, tests are on the beta board that arrived a couple of months ago. On pure CPU core + L1 cache tests (e.g. https://hoult.org/primes.txt) the LPi4A is considerably faster. The LPi4A is also much faster on memcpy tests. https://hoult.org/TH1520_memcpy.txt https://hoult.org/JH7110_memcpy.txt My build test is an RVV 0.7.1-enabled snapshot of the gnu toolchain (gcc 9.2) that I use on the TH1520 and SG2042 (and various chips with C906 cores with RVV 0.7.1). Newlib, non-multilib (just rv64gcv) build. I used the sam

Read the rest

e Samsung 2 TB external USB3 SSD drive for src/build trees on both boards. https://github.com/brucehoult/riscv-gnu-toolchain VF2: real 107m52.116s user 348m49.800s sys 16m27.529s LPi4A: real 122m16.099s user 400m17.737s sys 23m8.567s Neither board is thermal throttling at all. I have the supplied fan sitting loosely on top of the LPi4A CPU (I also try tests without the fan ... it throttles a lot, taking 166m on this test). The VF2 is without a fan -- doesn't need it. The LPi4A has more L1 cache, but only 1 MB of L2 vs 2 MB on the VF2. But the LPi4A's RAM is twice as fast as the VF2's L2 cache! At least for streaming -- I haven't tried random. It's a mystery.

In RISC-V Lichee Pi 4A vs. VisionFive 2 vs. HiFive Unmatched vs. Raspberry Pi 4B

snvzz·May 20, 2023

On a personal level, I prefer upstream not to have anything non-ratified. Companies that use these should bear the cost of maintaining the toolchain, not upstream. There's this tree[0] which has support. I thought it actually got merged, but I'm currently struggling to find anything about it. 0. https://github.com/brucehoult/riscv-gnu-toolchain/tree/rvv-0...

In RISC-V based Milk-V board with 64 cores at 2 GHz and 128 GB RAM