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>
Resolves#7521.
With this PR, `@...` suffixes are included in the clickable area for
go-to label.
This also affects PowerPC, where `@...` suffixes are a bit more common
(`@ha` and `@l` will also be marked as clickable).
---------
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>
[ORCA/C](https://github.com/byteworksinc/ORCA-C) is a C compiler that
natively runs on and targets the Apple IIGS. ORCA/C and the programs it
generates can be run on modern Linux systems by using an emulation tool
called [Golden Gate](https://goldengate.gitlab.io).
This adds support for ORCA/C (run via Golden Gate) in Compiler Explorer.
It uses its own assembly format and objdumper (provided by Golden Gate),
so support for those is added. An extra configuration option was also
added to support execution via an emulator, bypassing the usual check
that executables can run natively. Asm docs for the WDC 65C816 processor
were also added.
ORCA/C and Golden Gate are not Free Software, but their rights holders
have given permission for them to be used on Compiler Explorer. Tarballs
for them can be supplied privately. See infra PR:
compiler-explorer/infra#1521
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
Libraries were being fetched from wrong URL (on startup);
`Fetching remote libraries from
https://godbolt.org:443/api/libraries/c++`
Ended up refactoring a bunch of things to get some unittesting going on
I did not test actual startup and compilation with CE, I might have
broken something. (but @mattgodbolt tested and it looked great)
- Uses strings across the board in the UI part (no functional change
here from before; all state is the same as it was before).
- Sends _arrays_ in the POST, using the same `splitArguments` code as
the backend.
- Backend _still supports_ strings (though doesn't advertise), also
using same `splitArguments`.
- Moves `splitArguments` into common utils, and rephrases to avoid
unnecessary use of underscore and ES2021+ code.
Tested locally:
- with both old and new client code (ran new backend and old webcode to
show sending strings still works)
- with creating and removing tool windows (checked with `ldd` locally)
- with various strings on the client `moo foo "this is bad" #moo` and
even "error" things like `this is "badger` (with a missing close quote).
All works as you'd expect
Happy to break the "move the splitArguments" code into a separate PR if
that'd be easier to review separately.
Fixes#7195
Does some winter cleaning on the site-template stuff :)
1. Migrated away from the custom conf format to plain old yaml
2. Made the images and image files match with the name from the yaml
file. (It's not a problem to have spaces in file paths, nor urls so I
don't see why we shouldn't)
3. Updated the relevant documentation
There is a small breakage in the api response for the meta field. It now
returns `{"screenshot_dimensions":{"width":1000,"height":800}}` which I
believe is a lot more useful than
`{"meta.screenshot_dimensions":"1000x800"}`
Besides, I don't believe this endpoint has any third-party consumers
that rely on the metadata since it's a rarely known feature anyways
This is the first PR in API consistency with more to come:
1. The source API urls have been properly defined with
`/source/:source/list` and `/source/:source/load/:language/:filename`
- These used to be two API endpoints mushed together into one `handle()`
function. They are now separate
- While it may appear from the tests that this is an API breakage,
there's currently no way to have the source API spit out responses for
stuff like `/source/moose/load/Grunkle`.
2. The frontend code calling the list api now has shared types
3. Code has been migrated to `/lib/handlers/api/source.ts`
- I've moved code here, because I would like to separate the stuff
that's under the API and the stuff that isn't (e.g., healthcheck)
- The source endpoint is currently not under /api, but I believe it
makes sense to move it.
4. GitHub is terrible at showing the diff, but the `browser.ts` file has
been removed, since it's never actually used. Our frontend only calls
`/source/builtin/...` and it never had any entries. Besides, the type
used on the frontend for the locally stored stuff is different...
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!
1. Gives a proper type to the metadata
2. Fixes a typo in `screenshot_dimentions`
3. Removes home-made partition function in favor of underscore
4. Reads file asynchronously (and consequently rest of API is async)
5. Strips the `https://godbolt.org/#` from each entry in the config file
As an added benefit this should also cut some startup time reading this
file before it's used :)
This patch adds two options to the clangir pane that affects the clangir
compilation pipeline:
* Flat CIR enables the emission of flat clangir CFG;
* -fclangir-mem2reg enables the mem2reg pass on the flat clangir CFG.
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)
This includes among others:
- Proper tsification of various tools code,
- Elimination of the `CompilationInfo2` type,
- Use of `CompilationInfo` instead of `Record<any, any>` in some places
- These lines in CompilationResult:
```
// Temp hack until we get all code to agree on type of asm
asm?: ResultLine[] | string;
```
The next task would be to get all code to agree on the type of
CompilationResult.asm, thereby enabling fixing of most the remaining
TSification.
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
Still mostly mindless numb work, one rename that touched many files
(`getArgumentParser` -> `getArgumentParserCls`), and a few real
improvements.
The goal is to be able to turn on `noImplicitAny` for the project, to
enforce higher code quality. 600 violations to go.
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
Currently the clangir compiler is implemented by a special clang variant
whose compilation options list gets appended with `-Xclang -fclangir
-Xclang -emit-cir`. This introduces a problem: we no longer gets access
to its LLVM IR output and assembly output because `-emit-cir` is an
exclusive option.
This patch resolves this problem by introducing a new ClangIR pane,
similar to the LLVM IR pane or Rust MIR pane. A new output kind named
`ClangIR` is added to the "Add new..." drop down menu and it toggles the
ClangIR pane. This patch then removes `-Xclang -emit-cir` from the
options list of the clangir compiler. The clangir compiler will then
output assembly code just like other clang compilers. The removed
options will be added back when compiled from the ClangIR pane.
