Just-In-Time Compilation (libgccjit.so)

GCC can be built as a shared library "libgccjit.so", for generating machine code from API calls, using GCC as the backend.

This shared library can then be dynamically-linked into bytecode interpreters and other such programs that want to generate machine code "on the fly" at run-time.

It can also be used for ahead-of-time code generation, for building standalone compilers (so the "jit" part of the name is now something of a misnomer).

The library provides a C API, along with a C++ wrapper API, with bindings for languages available from 3rd parties (see below).

The API is very high-level, and is designed in terms of C semantics (since you're probably going to want to interface with C code).


libgccjit.so has been available in gcc since GCC 5, and we believe it has been API and ABI-compatible since then. See the API and ABI compatibility notes in the documentation.

The C API is mature at this point, though I'm open to adding new entrypoints to support functionality that I may have missed.

Although the C++ API ships within GCC, it should be regarded as more experimental that the C API.

The maintainer is David Malcolm <dmalcolm@redhat.com>

There are language bindings available from third parties for C#, D, OCaml, Perl, Python (2/3), and Rust.

Mailing list

There is a shared mailing list for both users and developers of the library: jit@gcc.gnu.org

You can subscribe by emailing jit-subscribe@gcc.gnu.org

The archives can be seen at: http://gcc.gnu.org/ml/jit/


Documentation for the API can be seen at: https://gcc.gnu.org/onlinedocs/jit/

Installation via packages

Fedora and RHEL


   1   sudo dnf install libgccjit-devel

should give you both the JIT library (libgccjit) and the header files needed to develop against it (libgccjit-devel):

Other distributions

TODO: what are the packages called in other distributions?

Building it from source

See the notes on working on the JIT library in the documentation.

Language Bindings

Who's using this code?


The idea is that GCC is configured with a special --enable-host-shared option, which leads to it being built as position-independent code. You would configure it with host==target, given that the generated machine code will be executed within the same process (the whole point of JIT).

libgccjit.so is built against libbackend.a. To the rest of GCC, it looks like a "frontend" (in the "gcc/jit" subdir), but the parsing hook works by replaying a record of the API calls made by client code.

You can see a diagram of how it all fits together at: http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/jit/notes.txt

The jit "frontend" requires --enable-host-shared, so it is off by default, so you need to configure with:

to get the jit (and see caveats above).

The library API hides GCC's internals, and tries to be much more typesafe than GCC's, giving something rather like Andrew MacLeod's proposed changes - client code does not see "tree", instead dealing with types, rvalues, lvalues, basic blocks, etc. It is pure C, given the horror stories I have heard about people dealing with C++ ABIs.

The API deliberately uses C terminology, given that it's likely that the user will want to be plugging the JIT-generated code into a C/C++ program (or library).


None: JIT (last edited 2021-09-17 22:44:47 by DavidMalcolm)