RISC-V support in the various toolchains is still a work in progress and can require bringing together source patches and non-default branches from multiple upstream projects. This creates a barrier for developers wishing to participate in expanding the RISC-V software ecosystem. Specifically, GCC won't have an official release with RISC-V autovectorization until gcc-14 (Spring 2024).

Imagination already produce packages for Windows, macOS and several Linux distributions which include bundled binaries of recent GCC and LLVM, packaged together with a small sysroot, support for a few CPUs (modelled and real hardware) and a VS Code IDE.

A single Catapult SDK package currently includes:

  • LLVM, version 16.0
  • GCC (13.1). We'd like to use the riscv/gcc-13-with-riscv-opts backport once stable (e.g. LTO had issues when we last looked)
  • C libraries including Musl, picolib and glibc
  • binutils
  • A software CPU model of some Imagination CPUs
  • Support (via OpenOCD and gdb) for debugging on a number of RISC-V platforms including HiFive1, VisionFive
  • Documentation and example applications, including FreeRTOS
  • A Visual Studio Code IDE that integrates all these features

This effort was to explore feasibility of providing binary toolchain releases.




Development TimelineNA


This is now available to all at our public GitHub site.

Please note that these are binaries.
Upstreaming of source code to the open source projects packaged in these binaries (e.g. LLVM) is continuous and ongoing.

Upstream Version


Simon Harvey



psABI vector ABI spec



  • Publicly available binaries now released without registration requirement


  • Project reported as priority for 2H23


  1. This is a good start, but figuring out how to get same-source bits out via Homebrew would lower the adoption barrier significantly as well.

  2. This should call out which branch we're trying to build and why (GCC-13 with backported patches? which ones?)

  3. maybe rename this to Binary Toolchain Packages for GCC-13? Or do you want to cover LLVM as well? if so, that should be separate anyway.

  4. We include GCC + LLVM + C libraries + debug support in a single package at present. I've included a bit more detail above.