AdaptiveCpp: one SYCL compiler, every vendor's GPU, and the trade-offs of a single binary

A SYCL implementation that refuses to pick a vendor backend

AdaptiveCpp was formerly called hipSYCL and then Open SYCL, and both names still appear in parts of the documentation and the code. What it is now is a community-driven implementation of SYCL, a C++-based heterogeneous programming model, maintained primarily by Heidelberg University with outside contributions. The pitch is that one source tree, and in the common case one binary, can target CPUs and GPUs from Intel, NVIDIA, AMD and Apple.

The CPU side covers x86, arm and other architectures LLVM supports. The GPU side is vendor-neutral by design rather than by accident, which is the whole point of the project: an application adapts to whatever hardware the system actually holds, including using hardware from two vendors in the same run.

The repository is licensed BSD-2-Clause, its default branch is develop, and the last push was on 2026-10-12. That is recent enough that maintenance claims are safe to make without qualification. Releases ship under a date-based scheme: v25.10.0 on 2025-11-05, v25.02.0 on 2025-05-09, v24.10.0 on 2024-12-20. The project is not archived.

The single-pass LLVM JIT is the default flow

Three compilation families are described. The default is a generic LLVM JIT compiler, which the project calls its most portable and usually most performant flow. Its distinguishing claim is structural: AdaptiveCpp describes itself as the only SYCL compiler that parses the source code a single time across both host and device compilation, published as one pass to bind them at IWOCL '23.

The second family exists for source-level interoperability with vendor programming models, including mixing CUDA and SYCL in one file. The third is library-only flows that defer to third-party compilers and use AdaptiveCpp purely as a library, which is the deployment-simplest option. The full matrix lives in doc/compilation.md, and doc/sycl-ecosystem.md places the project in the wider SYCL landscape.

The README also says that programs compiled with AdaptiveCpp work with vendor tools such as profilers and debuggers. It describes the project as both a research platform and a production solution, including on some of the most powerful supercomputers.

Compiling your first kernel with acpp

The README does not give a package-manager install line. Installation is handled by a separate document, doc/installing.md, reached from the installing and using section of the README, so go there for the build or package steps matching your platform. There is no snap, brew or apt shortcut documented in the README itself.

Once the compiler exists, you drive it with `acpp`, which is meant to be used like any other compiler driver. Compile a translation unit the way you would with gcc or clang:

acpp -o test test.cpp

That produces an executable named test from test.cpp. Configuration happens through both command line arguments and environment variables, and target selection is one of the things you drive that way. The full option list is what the driver prints itself:

acpp --help

For anything beyond a single file, CMake integration is documented separately in doc/using-acpp.md, which is the page to read before wiring the compiler into an existing build. The repository ships examples, including examples/bruteforce_nbody and its own examples/CMakeLists.txt, so you have a reference tree for how a project is expected to call the compiler.

Standard parallelism offloading is experimental, and the algorithm list is the contract

Beyond SYCL, AdaptiveCpp offers experimental offloading of C++ algorithms from the parallel STL. This is the feature with the boldest claim attached: the README states that AdaptiveCpp is currently the only solution able to demonstrate C++ standard parallelism performance across NVIDIA, AMD and Intel GPUs, and that in most cases it outperforms vendor compilers. That sentence is the project's own, and no measurement accompanies it in the README. If the claim matters to your decision, doc/stdpar.md and doc/performance.md are where to check the current algorithm coverage.

The operative detail is that coverage is documented per algorithm, not wholesale. doc/stdpar.md exists specifically to list which algorithms can be offloaded, which means the set is partial and can change between releases. A team porting an existing parallel STL program cannot assume every algorithm moves to the device; the code has to be checked against that list, and rechecked on upgrade, because releases are date-stamped and the default branch is develop.

Being experimental also means interface guarantees are soft. Nothing in the README commits to ABI or API stability for the stdpar surface across a version boundary.

Portable CUDA is the second experimental surface

PCUDA, described as portable CUDA, is a dialect of the CUDA and HIP programming model with experimental support. The stated goal is to compile CUDA or HIP code into a single binary that offloads kernels to CPUs, NVIDIA GPUs, AMD GPUs and Intel GPUs, which would let an existing CUDA codebase reach hardware its original toolchain could not.

This is the most attractive part of the project if you have CUDA code, and the least settled. The README labels it experimental support state and points to doc/pcuda.md. There is no compatibility matrix here listing which CUDA features are supported, and no statement about which CUDA standard the dialect tracks. Before planning a migration, read doc/pcuda.md and test your actual kernel patterns rather than a toy example.

The two experimental features share an origin. Both stdpar and PCUDA are contributions associated with Aksel Alpay and Vincent Heuveline at Heidelberg University, the same pairing behind the single-pass compiler and the JIT-time optimization work, so their maturity and their likely trajectory are tied to the same small group. That is a staffing fact worth weighing, not a criticism of the work.

Where this falls short

The clearest limitation is that two of the three headline programming models are experimental. If your roadmap depends on C++ standard parallelism offloading or on compiling CUDA across vendors, you are building on a surface its own README declines to call stable.

The second limit is documentation shape. Installation, compilation flows, CMake usage, algorithm coverage, PCUDA details and performance guidance are six separate documents under doc/, and the README explicitly warns that older names hipSYCL and Open SYCL still appear in places. Expect to read a lot before your first build, and expect to hit a search result that mixes both naming eras.

Third, AdaptiveCpp is a compiler you build and then rebuild. It targets LLVM and interacts with vendor stacks, and the README documents no binary distribution channel at all. For a team without build capacity, that alone can be disqualifying. Finally, the README does not document a rollback procedure for a bad release, so pinning a version is on you. And the leadership concentration is real: development is primarily led by one university, with the project itself framing this as an intentional contrast to vendor-driven compiler efforts.

How it differs from a vendor toolchain

AdaptiveCpp's default flow is a generic LLVM JIT compiler. The project says a single binary can target supported hardware from different vendors, including Intel, NVIDIA, AMD and Apple GPUs.

The README says vendor tools such as profilers and debuggers also work with programs compiled by AdaptiveCpp. For standard-parallelism coverage and performance details, it directs readers to doc/stdpar.md and doc/performance.md.

C++ standard-parallelism offloading remains experimental, and the README describes performance across NVIDIA, AMD and Intel GPUs without providing accompanying measurements.

Upgrade cost and licensing

Upgrading means moving between date-stamped releases such as v24.10.0, v25.02.0 and v25.10.0 and re-running your build, because the offloadable algorithm list in doc/stdpar.md is expected to move with the compiler. If you track the develop default branch you accept even more movement. Budget for a full rebuild each time rather than a library swap, and for a regression pass over any code that leans on stdpar or PCUDA.

The license is BSD-2-Clause, a permissive two-clause BSD license. It imposes no copyleft obligation on code compiled with the toolchain, which is what most adopters will care about; the compiler's own licensing does not change the licensing of a proprietary application built with `acpp`. Anyone needing certainty about distribution terms should read the LICENSE file in the repository root and consult their own counsel.

The project also asks research users to cite one of several publications depending on focus, covering the single-pass compiler, PCUDA, JIT-time optimization, stdpar and the CPU backend. That is a request, not a license condition.

Editorial conclusion

AdaptiveCpp fits teams that already write SYCL and must ship one binary across mixed Intel, NVIDIA, AMD and Apple fleets, and that have the build capacity to compile from source or track an independently versioned compiler. It does not fit a team that wants vendor tooling parity, a stable standard-parallelism path or a stable CUDA dialect, since both of those are marked experimental here. Before committing, check the compiler options in `acpp --help` against your device targets, read doc/installing.md for the build path you need, and confirm which standard-library algorithms doc/stdpar.md actually offloads in the release you pin.

Frequently asked questions

Official sources

1. AdaptiveCpp/AdaptiveCpp on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases