This PR adds [CO2](https://github.com/hkalbasi/co2) which is a language
backward compatible with C, with some Rust interop features that
compiles to Rust's MIR.
I added two compiler `co2rustc` and `co2cc`, and a tool `co2miri` which
is Miri for CO2. I added `co2cc` under C compilers, to make it possible
to view diff of assembly for a C code compiled with CO2 and clang or
gcc. `co2cc` is a CO2 frontend which accepts gcc-like flags, and can (or
at least should) compile almost every ISO compatible C23 code.
`co2rustc` accepts Rust like flags, and added under a new `CO2`
language.
Tested locally and it seems to work.
I need some help in setting up artifacts (which, if I understand
correctly, needs to happen in `infra` or `compiler-workflows`). I make
an artifact `co2-multicall` in my CI, which needs to get symlinked in
`co2cc`, `co2rustc` and `co2miri`, and it needs to run a simple project
with miri to create the miri sysroot. If you show me a similar project,
I will do the job.
Disclaimer: Written partially by LLM.
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
This adds support for
[RazorForge](https://github.com/dj-lumiere/razorforge-suflae),
a precision-focused, ahead-of-time compiled language that lowers to LLVM
IR. It follows
`docs/AddingALanguage.md`.
### What's included
- `lib/languages.ts` — language definition (`.rf`, Monaco mode
`razorforge`, disassembly `llvm-ir`)
- `types/languages.interfaces.ts` — `razorforge` language key
- `lib/compilers/razorforge.ts` + `lib/compilers/_all.ts` — compiler
driver
- `static/modes/razorforge-mode.ts` + `static/modes/_all.ts` — Monarch
syntax highlighting
- `etc/config/razorforge.{defaults,amazon}.properties` — compiler config
- `examples/razorforge/default.rf` — default example
- `.github/labeler.yml` — `lang-razorforge` label
### Compiler behavior
RazorForge's CLI takes verbs + positional arguments only (all build
config lives in
`razorforge.toml`, not flags). The driver invokes the `build` verb,
which runs semantic
analysis and code generation and writes LLVM IR next to the source
(`example.rf` →
`example.ll`) without invoking `opt`/`clang`. The primary output is the
emitted LLVM IR,
so `supportsIrView` is on and `supportsExecute` is off for now.
### Notes
- Install recipe: compiler-explorer/infra#2177
- No logo yet (`logoFilename: null`); happy to add one in a follow-up.
- Verified locally: `make`, `biome check`, `tsc`, and `vitest related`
all pass; the example
compiles to valid LLVM IR with the released `v0.0.3-alpha` build.
Automated fix by @leftibot.
### What changed
> Fix#8695: add Lua as a supported language
> Add support for Lua via the reference PUC-Rio interpreter. Disassembly
is
> produced by `luac -l -l -p`, which writes a verbose bytecode listing
to
> stdout that the LuaCompiler captures and writes to the output file.
The
> class exposes overridable hooks (`resolveLuacExe`,
`getDisassemblyArgs`)
> so alternative implementations such as LuaJIT can plug in a different
> bytecode dumper without rewriting the compiler. Production config
ships
> five Lua releases (5.1.5, 5.2.4, 5.3.6, 5.4.7, 5.5.0) covering the
> actively used minor versions.
### Files
```
etc/config/lua.amazon.properties | 27 ++++++
etc/config/lua.defaults.properties | 5 +
examples/lua/default.lua | 5 +
lib/compilers/_all.ts | 1 +
lib/compilers/lua.ts | 182 +++++++++++++++++++++++++++++++++++++
lib/languages.ts | 11 +++
test/lua-tests.ts | 138 ++++++++++++++++++++++++++++
types/languages.interfaces.ts | 1 +
8 files changed, 370 insertions(+)
```
Closes#8695
_Triggered by @lefticus._
---------
Co-authored-by: leftibot <leftibot@users.noreply.github.com>
Co-authored-by: Matt Godbolt <matt@godbolt.org>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Fixes
https://github.com/compiler-explorer/compiler-explorer/issues/5634.
Adds the Lean 4 language and compiler.
> Lean is an open-source programming language and proof assistant that
enables correct, maintainable, and formally verified code
Since it was first requested in
https://github.com/compiler-explorer/compiler-explorer/issues/5634, it
has become increasingly relevant due to interest in AI-assisted theorem
proving, formalized mathematics, and verified software.
---
Lean compiles in two steps: first to C source code using the `lean`
executable, and then to assembly using the `leanc` compiler distributed
with Lean (I believe it's Clang).
The PR also includes a pane to visualize the emitted C source code that
was modelled after the panes for Rust and Haskell IRs and after the C
preprocessor pane for clang-format integration. Lean outputs mostly
unindented C code, so I enabled the formatter by default.
See companion infrastructure PR at
https://github.com/compiler-explorer/infra/pull/2130.
<img width="3024" height="1720" alt="image"
src="https://github.com/user-attachments/assets/5e7a1e91-e748-4599-8190-d3cb09fca503"
/>
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
Don't define a `Run` (`main`) function. Remove comments mentioning
Carbon Explorer, since that has been unmaintained for several years, and
is very outdated at this point. Add "Type your code here" comment
matching the default for other languages.
Recent compilers do not allow parametric functions to be exported, so
remove the keyword. Note that this means the function now gets inlined
with default optimization levels.
As noted by Matt during his [Advent of Compiler Optimizations - Episode
20: Vectorization
[0:55]](https://www.youtube.com/watch?v=d68x8TF7XJs&t=55s), `const` can
and should be introduced here.
We don't need the elements of `y` to be modifiable.
Closes#8349
<!-- 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!
-->
<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>
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>
A while ago compiler explorer would only see exported functions of the
main package (and the main function).
I don't know when but at someone improved the flags passed to the go
compiler and it now sees all functions, even if you use the oldest go
compiler still supported.
Remove noise from the example and make it more like the C one.
This PR adds support for the Mojo programming language.
Explicitly tested viewing the generated assembly, LLVM IR, and running
the generated executable.
This adds support for the [Sail
language](https://github.com/rems-project/sail) - a DSL for defining
ISAs.
It's not quite ready but I need some help. These are the main remaining
issues:
1. When you "link to binary" it does disassemble the binary properly,
but the syntax highlighting and line numbers are broken.
2. If you try to execute the code without a `function main() -> unit =
...` then it gives this error in the compiler output:
```
Internal Compiler Explorer error: Error: spawn /tmp/compiler-explorer-compiler2025025-31052-c8gern.pf8t/model.c EACCES
at ChildProcess._handle.onexit (node:internal/child_process:285:19)
at onErrorNT (node:internal/child_process:483:16)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
Compiler returned: -1
```
This is weird - it should give a linker with an undefined reference to
`zmain`.
3. Sail compiles to C, and then I added extra steps to compile that to
binary (if you select `Execute the code`), but as you can see I had to
move the binary back over the C file, so in this case `model.c` is
actually an ELF file. It works but that seems very weird. There is a
`getExecutableFilename()` method I could override, but doing that seems
to make it even more confused.
4. I also had to have a fake flag for `binary` because the `filters`
don't seem to get set correctly when passed to `runCompiler()`. E.g.
`buildExecutable()` doesn't pass them at all. Not sure what is going on
there. Seems to work though.
Any help appreciated!
PS: Sail is a cool language. It has lightweight dependent type for
integers and bit vectors, which I haven't demonstrated in the examples
yet, but they're neat.
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
This fork provides a rudimentary way of using Coccinelle within Compiler
Explorer.
In the left window one can edit either C or C++ code, and within
preprocessor ifdefs, one can write a semantic patch for Coccinelle.
The right window will display the transformed code.
A coccinelle on infra is not yet done.
Any distribution-based coccinelle would do, for the moment.
If you like it, this close#6999 .
---------
Signed-off-by: Michele Martone <michelemartone@users.sourceforge.net>
Co-authored-by: Patrick Quist <partouf@gmail.com>
Co-authored-by: Mats Jun Larsen <mats@jun.codes>
Co-authored-by: Matt Godbolt <matt@godbolt.org>
Should be pretty self explanatory. I've added a corresponding PR to the
infra repo [here](https://github.com/compiler-explorer/infra/pull/1532)
Please let me know if there is anything I've done incorrectly here!
Thanks
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
- Add initial support for Numba compilation: asm, demangling, execution
Numba wraps Python functions in `Dispatcher` objects. Each dispatcher
contains zero or more compiled argument-type-indexed overloads of its
function. We import the user's code as a module, and emit the code from
all overloads of all dispatchers that the module publicly exposes.
Name mangling is odd in Numba. It uses a similar mangling syntax to C++,
but also encodes non-symbol (`r"[^a-z0-9_]"`) characters as `_%02x`.
This encoding yields valid identifier names, so it is not strictly
invertible. Here, I have hard-coded some replacements to decode some
common cases at the cost of possible clashes with ugly user-defined
names.
Screenshot captured via `make dev EXTRA_ARGS="--debug --language numba"`
## To do
- [x] Answer questions of #5591.
- [x] Acquire a python environment.
- [ ] Automatically run the python test?
Locally, I have installed a virtual environment with python 3.12.3 with
```shell
path/to/python -m venv venv_numba
path/to/venv_numba/bin/python -m pip install numba==0.61.0 scipy>=0.16
```
and configured its use with
```properties
# compiler-explorer/etc/config/numba.local.properties
compilers=&numba
defaultCompiler=numba_0_61_0
group.numba.compilers=numba_0_61_0
group.numba.baseName=Numba
compiler.numba_0_61_0.exe=/path/to/python3.13
compiler.numba_0_61_0.semver=0.61.0
```
I run this python-side test file with
```python
path/to/venv_numba/bin/python -m unittest etc/scripts/test_numba_wrapper.py
```
---------
Co-authored-by: Mats Jun Larsen <mats@jun.codes>
- Renames existing carbon stuff to carbon-explorer. Will need a quick
infra install and will temporarily (like, for 2m) break things during
deploy.
- Adds carbon binary support
- Supports binary, execute, and binary objects
- Updates the default carbon file as best I can
Closes#5402
This change makes full oatdump output visible behind the "Directives"
filter. This does the same thing as the --full-output flag, but is
more-easily used. The default code snippets have been updated to include
this.
Hello! I'm a big fan of Godbolt and use it regularly to test gas
optimizations in Solidity. However, to this day, there is no support for
Vyper, the second most popular language targeting the EVM, related issue
#4165. We at Statemind.io thought that adding Vyper support would
greatly benefit developers and security researchers, so here is our
attempt to get it working :)
This PR **is not ready** for merging, as `vyper.defaults.properties` and
`vyper.amazon.properties` are not yet defined. I have a few questions to
clarify how to integrate it on the public instance and infrastructure
repository:
Because Vyper compiler is basically a python module, I've found success
in testing multiple versions via separate `venv` environments. In my
local tests `vyper.local.properties` was the following:
```INI
compilers=vyper
compilerType=vyper
versionFlag=--version
compiler.vyper.exe=/opt/research/godbolt/venv/bin/vyper
compiler.vyper.isSemVer=true
compiler.vyper.instructionSet=evm
compiler.vyper.options=--optimize none
```
The versions tested are the latest major Vyper release 0.4.0, along with
0.3.10 and earlier 0.3.xx releases.
It appears that there is support for running python in a virtual
environment in the infra repository:
https://github.com/compiler-explorer/infra/blob/main/bin/lib/installable/python.py
However, I've had difficulties getting started with it and would greatly
appreciate any assistance. Thank you!
for https://github.com/compiler-explorer/compiler-explorer/issues/2331
Hey, so I am currently trying to improve the SPIR-V ecosystem, in-charge
of the [SPIR-V Guide](https://github.com/KhronosGroup/SPIRV-Guide), and
part of the SPIR-V Working Group. We talked at our last Face-2-Face
gathering about getting more support for GPU tooling in something like
Compiler Explorer because you have all made this such an amazing tool!
I have enjoyed working in this codebase and happy to help keep improving
the SPIR-V as people find issues or want enhancements (I was already
about to spend time rebuilding Compiler Explorer, so happy to donate my
time to a single tool's effort)
(For those who haven't spent last few years staring at SPIR-V)
- SPIR-V is a an IR (very much like LLVM IR) but for GPUs
- SPIR-V can be used for Graphics and Compute
- Compute:
- Can be tied to things like clang, llvm, mlir, OpenCL, etc
- One could take `spirv` as a language and compile it to something like
x86
- (Future PRs for this realm of things)
- Graphics:
- Much harder to actually "compile" to any ISA because other graphics
pipeline information is missing that will effect the final ISA
- Microsoft has even now planned to move to [SPIR-V for DirectX
soon](https://devblogs.microsoft.com/directx/directx-adopting-spir-v/)
- Both:
- There are many tools that run on SPIR-V regardless (hence why they
share the same IR)
- Being able to do tooling in compiler explorer would be AMAZING
This PR adds `SPIR-V` as a language and a new `SPIRV-Tools` compiler as
an initial compiler for it the language (since we already have the
SPIRV-Tools repo being pulled in on the infra side!)
I personally use `spirv-opt` and `spirv-val` the most and have been
testing this locally for a few days and feel it is ready to go. I plan
to slowly add more tools (ex. `spirv-fuzz`, `spirv-cross`,
`spirv-reflect`, etc)
Cheers!
(some screenshots of course)
Hi dear godbolt team,
> Before opening the PR, please make sure that the tests & linter pass
their checks,
> by running `make check`.
With this pr i added support for the ylc compiler.
Infra-PR: https://github.com/compiler-explorer/infra/pull/1441
Supersedes #6842
- We now have the upstream issue of `JitDisasmAssemblies` fixed. Enable
it for net9.0+.
- Update asm-parser to support CoreCLR and NativeAOT (Fixes#6833)
- Adding support for IL language
- Adding support for IL disassembler
- Fixes#6629
As the circt project has evolved over the past two years, the old
example no longer work with the current circt compiler. This commit
corrects the IR examples according to the new HW dialect, Seq dialect
definitions.
