We only support running .NET code on CoreCLR and Mono, so we should reject execution on other compilers otherwise this can confuse users a lot.
In addition, removing the --notrimwarn and --noaotwarn so that users can see warnings during NativeAOT compilations, and adding missing arguments to ilc.
- [x] Ensure `CLJ_CACHE` environment variable is set to a writable
directory
- [x] Remove unnecessary `CLJ_CONFIG` environment variable
- [x] ~~Configure location of `clojure_wrapper.clj` (not necessary)~~
- [x] Remove logging of namespace injection - text output causes UI to
show compiler error flag
We currently retain only StackMap, but InlineInfo is also useful.
<!-- THIS COMMENT IS INVISIBLE IN THE FINAL PR, BUT FEEL FREE TO REMOVE
IT
Thanks for taking the time to improve CE. We really appreciate it.
Before opening the PR, please make sure that the tests & linter pass
their checks,
by running `make check`.
In the best case scenario, you are also adding tests to back up your
changes,
but don't sweat it if you don't. We can discuss them at a later date.
Feel free to append your name to the CONTRIBUTORS.md file
Thanks again, we really appreciate this!
-->
Fixes#8273
The default NASM output format was `elf` (32-bit ELF), causing a
spurious `64-bit unsigned relocation zero-extended from 32 bits
[-w+zext-reloc]` warning when using 64-bit addressing (which is the
common case on CE's x86-64 infrastructure).
Changed the default to `elf64`. Users who explicitly need 32-bit ELF
output can still pass `-felf` to override.
*(I'm Molty, an AI assistant acting on behalf of @mattgodbolt)*
Co-authored-by: mattgodbolt-molty <mattgodbolt-molty@users.noreply.github.com>
*(I'm Molty, an AI assistant acting on behalf of @mattgodbolt)*
Closes#5178
## Problem
NVCC embeds the CUDA fat binary blob in the host-side x86 assembly
inside a `#APP`/`#NO_APP` inline-assembly block, under a label called
`fatbinData`. In a realistic kernel this can be 100+ lines of `.quad`
hex values — a wall of noise before any user-readable code.
Example: https://godbolt.org/z/W3YMcq8oY
## Fix
Per-compiler pre-processing step in `NvccCompiler.processAsm()`: before
the host assembly reaches the ASM parser, any `#APP`/`#NO_APP` block
containing a `.nv_fatbin` section is stripped out entirely.
- Only `.nv_fatbin` blocks are removed; genuine user inline-assembly
blocks (which also use `#APP`/`#NO_APP` but without `.nv_fatbin`) are
left intact.
- Intentionally NVCC-specific — no changes to the base `AsmParser`, no
false-positive risk for other compilers.
- Stripping happens before `findUsedLabels` runs, so `fatbinData`
naturally disappears as unreferenced without any special-casing in the
parser's label-filtering logic.
- Gated on the existing Labels filter: with no filters active everything
remains visible; with Labels on the blob disappears.
## Testing
**New compiler unit tests** (`test/compilers/nvcc-tests.ts`):
- Strips `#APP`/`#NO_APP` blocks containing `.nv_fatbin`
- Preserves `#APP`/`#NO_APP` blocks without `.nv_fatbin` (user inline
asm)
- Handles multiple mixed blocks correctly
- No-op when no `#APP` blocks present
- Gracefully handles malformed unclosed blocks
**New parser filter-case**
(`test/filters-cases/nvcc-x86-host-example.asm`): representative NVCC
12.0 host assembly (real 15-line fat binary, boilerplate functions,
`.nvFatBinSegment` section) with nine filter-combination snapshots
documenting parser behaviour in isolation. These correctly show that the
**base parser itself does not filter `fatbinData`** — that's the
compiler pre-processor's job.
All 767 tests pass.
Co-authored-by: mattgodbolt-molty <mattgodbolt-molty@users.noreply.github.com>
Today we only support passing options to the codegen backend, but not
the compiler that produces IL.
This change adds a new pseudo-option `-compopt`/`--compiler-options` so
that options follow after this pseudo-option can be passed to the
compiler that produces IL.
m68k GAS uses `|` as the comment character instead of `#`.
The base asm parser doesn't recognise this, so inline asm source
location markers (e.g. `| 2 "file.c" 1`) leak through into the output
instead of being filtered.
Repro on godbolt.org: https://godbolt.org/z/vYneWc8Tf
---------
Co-authored-by: Patrick Quist <partouf@gmail.com>
Adds support for [TinyGo](https://tinygo.org/), an LLVM-based Go
compiler targeting microcontrollers and WebAssembly.
## Changes
- **New `TinyGoCompiler` class** (`lib/compilers/tinygo.ts`): Extends
BaseCompiler with TinyGo-specific handling:
- Forces binary mode (TinyGo has no `-gcflags=-S` equivalent — it's
LLVM-based, not gc)
- Sets up `TINYGOROOT`, `GOROOT`, and `PATH` environment variables
- Uses `tinygo build -o <output>` as the compilation command
- User arguments (e.g. `-opt=2`, `-gc=none`, `-scheduler=none`) pass
through directly
- **Config**: Adds TinyGo 0.37.0 to `go.amazon.properties`
- **Registration**: Exports `TinyGoCompiler` from `_all.ts`
## Why TinyGo?
TinyGo produces significantly smaller binaries than standard Go (445KB
vs 1.5MB for a hello world). It targets a different niche —
microcontrollers, WASM, and resource-constrained environments — making
it an interesting comparison alongside the existing gc and gccgo
compilers.
## Testing
Tested locally with CE running on a non-default port:
- ✅ Compiler detected and version parsed correctly
- ✅ Compilation produces x86 assembly via objdump (5000+ lines for a
simple program)
- ✅ Execution works (`println` output captured correctly)
- ✅ User arguments like `-opt=2` pass through correctly
- ✅ All pre-commit checks pass (ts-check, lint, properties validation,
related tests)
## Infra
TinyGo 0.37.0 is already configured in the infra repo
(`bin/yaml/go.yaml`) — installation is just a tarball download from
GitHub releases.
The config references `/opt/compiler-explorer/golang-1.24.2/go` as
GOROOT — TinyGo needs a standard Go installation for the stdlib.
Closes#3969🤖 Generated by LLM (Claude, via OpenClaw)
---------
Co-authored-by: mattgodbolt-molty <mattgodbolt-molty@users.noreply.github.com>
Add ca65 as a standalone assembler under the Assembly language, reusing
the existing cc65 toolchain installations (2.17, 2.18, 2.19, trunk).
ca65 generates a listing file with full macro expansion (`-x -x`) so
users can debug macro output — the primary use case from the feature
request.
**What's included:**
- `Ca65Compiler` class — runs ca65, captures the listing output
- `AsmParserCa65` — parses the ca65 listing format (address, hex bytes,
source)
- Config for all 4 existing cc65 versions as ca65 assemblers
- Include paths set to each version's `asminc` directory
**How it works:**
Since ca65 produces object files in cc65's custom format (not ELF), we
can't objdump them. Instead, we use ca65's `-l` (listing) flag with `-x
-x` (full macro expansion) and `--list-bytes 0` (unlimited hex bytes per
line). The listing shows addresses, generated bytes, and expanded source
— exactly what users need for macro debugging.
Closes#7118
Co-authored-by: mattgodbolt-molty <mattgodbolt-molty@users.noreply.github.com>
Enable Biome's `organizeImports` with groups matching the original
ESLint `import/order` configuration:
1. **Node builtins** (`node:fs`, `path`, etc.)
2. *(blank line)*
3. **Third-party packages** (`express`, `@sentry/node`, etc.)
4. *(blank line)*
5. **Local/relative imports** (`../foo.js`, `./bar.js`, aliases)
This resolves the inconsistency where Biome wasn't enforcing import
grouping, meaning new files would lose the blank-line separation that
the old ESLint config enforced.
### Impact
- **354 files** updated out of 738 checked (~48%)
- **+188 / -240 lines** (net -52) — almost entirely single blank line
additions/removals between import groups
- No import reordering; purely group separator consistency
Fixes#7373🤖 Generated by LLM (Claude, via OpenClaw)
This depends on https://github.com/compiler-explorer/infra/pull/1936
which builds the runtimes when installing the Carbon toolchain. Then
this PR passes `--prebuilt-runtimes` to the `carbon link` step in order
to use them. The result is that compiler explorer no longer times out
when trying to link a binary with the Carbon toolchain.
The carbon.ts file is refactored a little in an attempt to improve
clarity about what is going on, and some comments are added throughout.
Fixes https://github.com/carbon-language/carbon-lang/issues/6603.
in `dev-2025-02`, odin changed from single-module debug builds to
multi-module and prevents it from spitting out a single `.s` file. this
adds version checking to make sure that any odin version after
`dev-2025-02` uses `-use-single-module`. additionally, changes were made
around name canonicalization that required changing the matching for
label names to avoid clogging the assembly output (both standard and
binary)
The existing heuristics don’t reliably recognise LLVM IR produced by
`rustc` (e. g. when the generated code does not use any LLVM
intrinsics), so this adds LLVM IR detection based on the
`--emit=llvm-ir` and `--emit llvm-ir` command line flags.
## What
Adds support for seeing Yul (Solidity IR) as intermediate output when
compiling Solidity.
This PR also enables that view for the Resolc compiler.
### Main Additions
- [x] Support viewing Yul in a supplementary view
- Solidity compilers can enable this by setting
`this.compiler.supportsYulView = true` in the compiler's constructor
- If custom processing of the Yul output or the Yul output filename is
needed, the compiler can override `processYulOutput()` or
`getYulOutputFilename()`
- [x] Enable the Yul view for Resolc
- [x] Implement a Yul backend option for filtering out debug info from
the output
### Notes
Source mappings are currently not handled for Yul -> Solidity.
## Overall Usage
### Steps
* Choose Solidity as the language
* Choose a Resolc compiler
* View intermediate results:
* Yul
* (Hide/show debug info by toggling "Hide Debug Info" in the Yul view
filters)
## Screenshots
<img width="1502" height="903" alt="ce-yul-view"
src="https://github.com/user-attachments/assets/ccc897e2-cd8d-4c33-962c-522d60b63134"
/>
The same race condition that was reported in #7012 also affects the opt
pipeline view.
I couldn’t reproduce the race condition locally, but on the live site it
happens relatively often, e. g. in https://godbolt.org/z/4Y1qfvTvz.
<img width="1405" height="474" alt="Clojure in Compiler Explorer 2"
src="https://github.com/user-attachments/assets/76dfed9b-d0eb-4764-b371-9c6023088a50"
/>
With Macro Expansion:
<img width="1642" height="594" alt="image"
src="https://github.com/user-attachments/assets/8b511af9-3617-426e-868d-5a99e5db5756"
/>
TODO
- [x] Language configuration
- [x] Compile via wrapper
- Inject namespace if necessary to simplify minimal code sample
- Parse Unix style command line parameters into compiler bindings
- Place file in path according to namespace
- [x] Install some versions of Clojure [PR
here](https://github.com/compiler-explorer/infra/pull/1849)
- [x] Macroexpansion view (modeled on Rust macro expansion view)
- [x] Filter out command line options that would break wrapper operation
- [x] ~~Parse `--help` output to a list of options~~ Reverted because
not applicable.
- [x] Short form compiler options
- [x] Support Clojure compiler settings via env var, like
`JAVA_OPTS=-Dclojure.compiler.direct-linking=true
-Dclojure.compiler.elide-meta=[:doc,:file]`
NOT DOING
- [x] ~~Support loading dependencies~~ Non-trivial enhancement. Not
necessary for initial release.
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
## What
Adds [Revive's Resolc](https://github.com/paritytech/revive) compiler
for compiling Solidity and Yul (Solidity IR) to RISC-V and PolkaVM
assembly.
### Main Additions
- [x] Implement new `ResolcCompiler`
- [x] Implement Yul language definition and config for Monaco
- [x] Add Resolc as a compiler for the Solidity and Yul languages
- The `ResolcCompiler` handles both kinds of language input
- [x] Implement initial `PolkaVMAsmParser` (no source mappings)
- [x] Enable viewing LLVM IR in a supplementary view
- [x] Implement a new LLVM IR backend option for toggling between
optimized and unoptimized ll
- Affects non-resolc files ([see
commit](606bab9a59))
- Disabled by default
- (Enable by setting `this.compiler.supportsIrViewOptToggleOption =
true` in a compiler's constructor)
- The compiler's `getIrOutputFilename()` will receive the LLVM IR
backend options
### CE Infra
Accompanying CE Infra PR:
https://github.com/compiler-explorer/infra/pull/1855
## Overall Usage
### Steps
(See screenshots)
* Choose between two input languages:
* Solidity
* Yul (Solidity IR)
* Choose a Resolc compiler
* View assembly:
* PolkaVM assembly (if enabling "Compile to binary")
* RISC-V (64 bits) assembly
* View intermediate results:
* Optimized LLVM IR (if enabling "Show Optimized" in the LLVM IR view)
* Unoptimized LLVM IR
### Notes
Source mappings currently only exist between:
- Yul and RISC-V
- Yul and LLVM-IR
## Screenshots
<img width="1502" height="903" alt="CE Yul RISC-V LLVM IR"
src="https://github.com/user-attachments/assets/7503b9b5-0f2c-4ddf-9405-669e4bdcd02d"
/>
<img width="1502" height="903" alt="CE Solidity PolkaVM"
src="https://github.com/user-attachments/assets/eeb51c99-3eaa-4dda-b13c-ac7783e66cb8"
/>
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
This adds support for the LLVM IR view for Swift, based on what other
LLVM based compilers do.
I tested it on my machine and it seems to work well, including with the
demangler. I'm not sure what `minIrArgs` is though, I added it because
it was there for other languages.
Co-authored-by: Nathan SALAUN <nathan.salaun@sofia.dev>
## Summary
- Removes misleading error log in Java bytecode parser for legitimate
compiler behavior
- Some Java-family compilers (Clojure, Kotlin) generate initial bytecode
instructions without source line mappings
- The code already handles this correctly; the error log was spurious
## Context
Issue #2986 has been open since 2021 with error logs about "Skipping
over instruction even though currentSourceLine == -1". After analyzing
the code path and compiler behavior:
1. **The "error" is actually expected behavior**: When compilers
generate bytecode with LineNumberTables that don't start at instruction
0, the initial instructions legitimately have no source line mappings
2. **The code handles this correctly**: These instructions are displayed
without source associations, which is the right behavior
3. **No functional issues**: After 3+ years, no users have reported
actual problems related to this
As @frankleonrose noted in the issue, this is legitimate compiler
output, not a CE bug.
## Test plan
- [x] TypeScript type checking passes
- [x] Linting passes
- [x] Java-specific tests pass (10/10)
- [x] Related tests pass (77/77)
Closes#2986🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude <noreply@anthropic.com>
* Minor updates only
* Added explicit radix parameter (10) to all Number.parseInt() calls throughout the codebase (new lint rule)
* Updated several @ts-ignore comments to @ts-expect-error for better TypeScript practices (new lint rule)
* Removed unnecessary @ts-ignore comments in some mode files (ditto)
* Used "none return" based arrow functions for some map stuff
* Replaced a `map()` call that didn't return anything to a for() loop
* Fixed up some cypress stuff, noting work for the future
- Made parsers stateful instances instead of shared static state (for
mllvm options). Fixes#8011 as this is caused by multiple clang-based
compilers being run concurrently and stomping over each others' state.
- passes `Compiler` to the constructor, which removes some param passing
- Added some missing awaits
- Tried to get things less dependent on `examples`, only `go` needs it
- Spotted that `zig` c++ might have issues in discovery
- Fly-by fixed a broken go path in ppc64le_gl122
- removed a redundant override in coccinelle
- made the mojo parser actually use the parser it defined
- canonified tablegen's special method
-
I changed the zig parser too but as best I can tell it was broken before
(the `1` return value from the command it runs:)
```
ubuntu@ip-172-30-0-164:/infra/.deploy$ /opt/compiler-explorer/zig-0.14.1/zig c++ -mllvm --help-list-hidden /infra/.deploy/examples/c++/default.cpp -S -o /tmp/output.s
...
--x86-use-vzeroupper - Minimize AVX to SSE transition penalty
--xcore-max-threads=<number> - Maximum number of threads (for emulation thread-local storage)
/infra/.deploy/examples/c++/default.cpp:1:1: error: FileNotFound
```
return code 1 (means it's not cached)
---------
Co-authored-by: Partouf <partouf@gmail.com>
Close#5530. Infra:
https://github.com/compiler-explorer/infra/pull/1711. Previous work by
@siboehm at #5531
## Summary
This pull request introduces support for the
[Triton](https://github.com/triton-lang/triton) language, a Python-based
DSL for writing highly efficient GPU kernels.
- [x] **New Language Support**: I've added comprehensive support for the
Triton programming language, allowing users to compile and inspect
Triton kernels within Compiler Explorer. (c.f.,
`lib/compilers/triton.ts`)
- [x] **Python Wrapper for Compilation**: A new Python wrapper script
(`triton_wrapper.py`) has been introduced to manage Triton compilation,
patching its behavior to dump compiled kernels and intermediate
representations without requiring actual execution, and consolidating
the output for Compiler Explorer.
- [x] **Device Assembly View**: Enables viewing of generated device
assembly code (e.g., PTX, AMDGCN) and various intermediate
representations (MLIR, LLVM IR) produced by the Triton compiler.
- [x] **MLIR Parsing**: New parsers (`asm-parser-mlir.ts` and
`mlir-pass-dump-parser.ts`) have been added to correctly interpret and
display MLIR assembly and optimization pass dumps, including source
location information.
- [x] **Multi-Version & Multi-Backend Support**: Painstakingly includes
all 8 versions (from 2.2.0 to 3.3.1) of Triton that supports Python
3.12. Supports both CUDA and HIP backend for Triton 3.
## Screenshots
Source and assembly:
<img width="1354" height="789" alt="image"
src="https://github.com/user-attachments/assets/c29650ff-2073-40e0-a9e6-ff8377094b5e"
/>
Device view for MLIR and LLVM IR:
<img width="1402" height="670" alt="image"
src="https://github.com/user-attachments/assets/43dd5c68-ca78-41b1-9865-e97ffe3ef73c"
/>
Opt pipeline viewer:
<img width="1408" height="668" alt="image"
src="https://github.com/user-attachments/assets/429eef8c-aaac-4781-aafa-39ef0ffc7241"
/>
Diff of TTIR in Triton 3.3.1 vs 2.3.0:
<img width="1580" height="726" alt="image"
src="https://github.com/user-attachments/assets/a928c893-dd9a-4c3a-a048-14046e56a14c"
/>
CUDA & HIP:
<img width="1596" height="800" alt="image"
src="https://github.com/user-attachments/assets/c18800c3-cfad-4e5e-96de-ba92c9f236ea"
/>
## Implementation Details (and Notes for Reviewers)
- For Device Assembly View, I Implemented `MlirAsmParser` for parsing
MLIR assembly. Technically MLIR is not an assembly language, but there
is no better choice to make the source line map work w/ device view.
- I Implemented `MlirPassDumpParser` for processing MLIR optimization
pass dumps. I tried to subclass `LlvmPassDumpParser`, but they turn out
to be too different to worth doing it.
- `LlvmPassDumpParser` made some assumptions that do not hold true for
MLIR passed. Some effort is put to make sure that the passes are
properly diff-ed, since some passes can run multiple times and also
sometimes pass can be nested (i.e., some number of `before`s followed by
some number of `after`s)
- A lot of effort is put into `patch_triton` to make sure that the we
only compile the kernel without actually running it, and that needs to
work across all the versions we support.
## Steps to Run Locally
1. Clone https://github.com/ShawnZhong/compiler-explorer-infra.git
2. Install Triton to `/opt/compiler-explorer/triton`:
```sh
$ cd compiler-explorer-infra
$ ./bin/ce_install install triton
$ ls /opt/compiler-explorer/triton
# v2.2.0 v2.3.0 v2.3.1 v3.0.0 v3.1.0 v3.2.0 v3.3.0 v3.3.1
```
3. Clone https://github.com/ShawnZhong/compiler-explorer.git and
checkout branch `triton`
4. Run Compiler Explorer
```sh
make EXTRA_ARGS='--language triton' dev
```
5. Enjoy
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
