ROSE: a compiler framework for building source and binary analysis tools

A compiler infrastructure rather than a compiler

ROSE is an open source compiler infrastructure to build source-to-source program transformation and analysis tools for large-scale Fortran, C, C++, OpenMP, Cuda and UPC applications, with support for Java and Ada, and analysis of binary files. The project description calls it an open-source compiler framework engineered by LLNL.

The distinction from a compiler matters. A compiler turns source into an executable, and ROSE does not. What it does is parse code into a complete Abstract Syntax Tree that contains all the syntax and semantic information in the original code, and it provides a rich API for querying that tree, reporting on it, changing it and emitting new code from it.

The stated audience is narrow and the README is honest about it: the intended users are either experienced compiler researchers or library and tool developers who may have minimal compiler experience. That second group is the interesting one. A tool developer who wants to find every function call with a certain argument pattern across a large Fortran and C++ codebase has, in ROSE, an AST with the semantic information already resolved rather than a set of regular expressions over text.

The library is also positioned explicitly against the obvious alternatives. ROSE is not grep, not sed, not LLVM and not a Perl script. The argument is not that those tools are bad, it is that they do not have an AST. A tool built on ROSE can precisely replicate the parsing and semantic analysis behaviour of multiple compiler languages, vendors and versions, which is what makes it possible to write an analysis that is correct about types, overloads and scopes rather than approximately correct about text.

The language and binary coverage in detail

The coverage list is the project's strongest argument and it is worth reading precisely.

On the source side the README describes ROSE as supporting large-scale Fortran across 77, 95 and 2003, C up to C23, C++ up to C++17, OpenMP, Cuda and UPC applications, plus Java 7 and Ada 95. The project description names the same set and adds that the C and C++ support covers applications which use UPC, OpenMP or Cuda.

On the binary side the list is what distinguishes ROSE from most source-level tools. It supports ELF and PE binary formats, and it analyses binaries which use ARM, AMD64, x86, MIPS, Motorola 68k, PowerPC in both 32 and 64 bit, Java byte code or CIL instruction sets.

The binary capability is not a bolt-on. It is what lets a tool built on ROSE work on a program it has no source for, which is a large fraction of the interesting security and reverse engineering problems, and it is why the project is also listed as suitable for cyber-security work. A tool that can lift an x86-64 binary into an AST and reason about it structurally is doing something a source-level tool cannot.

The description also names the use cases the framework is built for: custom tools for static analysis, program optimization, arbitrary program transformation, domain-specific optimizations, complex loop optimizations, performance analysis and cyber-security. The word that connects them is custom. ROSE is the substrate on which a specialised tool is written, not the tool itself.

Building it, and the EDG dependency that shapes the build

ROSE requires CMake version 3.15 or newer, and the installation instructions are short because the project uses the standard out-of-source CMake pattern. The example enables C support only, even though the framework supports many languages:

mkdir rosebuild
cd rosebuild
cmake .. -DCMAKE_INSTALL_PREFIX=/path/for/ROSE/install \
         -DENABLE_C=ON
make -j${NUM_PROCESSORS} install

The language flags follow the ENABLE pattern, so a build for a different language set changes which of them are on, and the install prefix is set at configure time.

The significant constraint is the next section. When ROSE is configured with c and c++ support it is required to download an EDG binary, and the README states that these are currently generated for GCC 7 through 12, that support for 11 and 12 is in progress, and that for fully supported versions you should use GCC 7 through 10. When not using c and c++ support, GCC 7 through 13 are supported.

That split explains a lot about how the project is used. The C and C++ front end is not a from-scratch parser, it is the EDG front end, which is proprietary software distributed in binary form to open source projects. The consequence for a user is a version matrix with two axes: which EDG binary you fetch and which GCC version it was generated for, and a support statement that is explicitly uneven, with two of the five listed versions still in progress and a clear recommendation of an older range if you want a fully supported configuration.

It also means the build is not fully self-contained. Anyone building ROSE for C or C++ is downloading a binary artefact as part of a source build, which matters for reproducible builds, for air-gapped environments and for corporate policy about third-party binaries.

The directory layout tells you how the project is organised

The repository is laid out in a way that makes the distinction between framework and tools visible, and the README's own directory list is the clearest guide.

src/ holds all the source code for ROSE itself, which is the infrastructure. tools/ holds usable, feature complete tools, the ones you can point at a codebase and get a result. projects/ holds tools that are in development and incomplete. tutorial/ holds examples of ROSE features, and docs/ holds the files for building the documentation.

The separation between tools and projects is the one to watch. A directory full of completed tools is a signal about what the framework can do out of the box; a directory of projects in development is a signal about what people are trying to build with it. Both are useful signals, and for a prospective user the second is often more informative, because it shows the shape of the tools people find worth writing.

The rest of the top level shows the project's history and its ambitions. There is CMakeLists.txt alongside the older configure.ac and Makefile.am, so both build systems are present. There is a cmake/ directory and a cmake-integration/ directory, which is the direction of travel, and a build/ directory. The exampleTranslators/ directory is a direct answer to the question of what a transformation tool looks like here.

Other directories indicate the range: python/ for scripting bindings, scripts/ for tooling, utilities/ for helper programs, acmacros/ for the autoconf machinery, config/ for configuration files, and a winspecific/ directory for Windows specifics. There is a LicenseInformation/ directory, which is how a project with third-party code in its tree keeps track of what came from where, and a NOTICE file next to it. The .claude/ directory at the top suggests the project is also being worked on with an AI coding assistant.

Documentation lives in the wiki and in Doxygen

The README is short and points elsewhere for the details, which is a reasonable choice for a project this size but does mean the README alone will not get you started.

There is a ROSE Doxygen API hosted at rose-compiler.github.io, and the README describes how to build the same documentation locally: go to the docs/Rose directory inside your build tree and run make doxygen_docs, and the generated HTML pages end up in a directory under the build tree that you can point a browser at. Building the API docs locally is a normal expectation for a C++ framework of this size, since the public API is large.

The wiki at the github wiki URL is where the README sends you for how to use ROSE, and there is a note about a Contributor Guide. The release cadence is fast. Recent tags are v2.18.0 from 2026-10-05, v2.19.0 from 2026-10-12 and v2.20.0 from 2026-10-19, which is one release a week, and the last push to the repository was on 2026-10-18.

The default branch is weekly, which explains the tag cadence and tells you something about the workflow: there is a branch that receives changes continuously, and releases are cut from it. The licence is BSD, with the README noting both the BSD License and the SPDX identifier BSD-3-Clause, and the project carries an LLNL licence code, LLNL-CODE-2018981, which is the identifier Lawrence Livermore National Laboratory uses for the licensing of its released code.

Where ROSE is the wrong tool

The first limitation is build weight. This is a C++ compiler infrastructure with a large API, a multi-language front end and a proprietary binary dependency in its build path. The installation is three commands, but the compile that follows is not a small thing, and the tool that comes out of it is a multi-gigabyte program that links against a large shared library. A team that needs to find one pattern in one language should reach for a language-specific analysis tool or a library with a real parser, and will get an answer in an afternoon rather than a week.

The second limitation is the uneven C and C++ support described earlier. The documentation is candid that the support for GCC 11 and 12 is in progress and recommends GCC 7 through 10 for fully supported versions, which means a project standardising on a recent compiler is choosing between a supported configuration and a recent one. That is a real decision with a real cost, and it is the kind of thing to resolve before writing a tool rather than after.

The third limitation is the learning curve the README itself names. The intended users are experienced compiler researchers or developers with minimal compiler experience, which is a description of a project where the AST API is the interface and the interface is large. There is a tutorial directory, and for a research prototype that is often enough, but for a production tool the gap between the tutorial example and a working analysis is wide.

The real alternative is LLVM, and the difference in approach is instructive rather than a matter of taste. LLVM is a set of libraries for building compilers, with a well-known intermediate representation at its core, and a large ecosystem of tools built on it. ROSE is a set of libraries for building tools, centred on a multi-language AST with the front ends already built, including a binary analysis capability and a source-to-source transformation model with a complete API. LLVM gives you a lower-level and more composable substrate, and you assemble the front end yourself; ROSE hands you finished front ends for many languages and the transformation framework on top. The trade is control against breadth. If you are writing a tool for one language and want full control over the intermediate representation, LLVM is the better substrate. If you need to handle a Fortran 2003 codebase and an ARM binary in the same tool, ROSE saves you the part of the job that is not your research.

Editorial conclusion

Adopt ROSE if you are building a static analysis or source-to-source transformation tool that needs a complete AST with semantic information across several languages, and if you can accept a build that pulls a licensed EDG binary and compiles for hours. Do not adopt it for a one-off script, for a project that only needs to target one language with an existing toolchain, or if you need a lightweight parser rather than a compiler front end. Before you commit, check which EDG and GCC version combination you will build against, because the documentation says the support for GCC 11 and 12 is in progress and recommends 7 through 10 for fully supported versions, and read the wiki for the API guidance the README defers to.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. llnl/rose on GitHub
4. README
5. Releases