Assembly documentation tooltips always display Intel syntax information,
but when the actual assembly output is in AT&T syntax, this can be
confusing due to the reversed operand order (AT&T uses source, dest
while Intel uses dest, source).
This change adds a warning to the tooltip when the assembly output is
NOT in Intel syntax, informing users that the documentation pertains to
Intel syntax.
The warning appears when:
- The user has not enabled the Intel syntax filter (filters.intel is
false)
- The assembly output is therefore in AT&T syntax
The detection uses filters.isSet('intel') rather than compiler.intelAsm,
ensuring we check the actual output syntax (what the user selected)
rather than just whether the compiler supports Intel syntax.
Fixes#4311
refactor: move assembly-syntax type to frontend, remove from device-view
Move types/assembly-syntax.ts to static/assembly-syntax.ts since it's
only used by frontend code (compiler.ts and device-view.ts), not
backend.
Per CONTRIBUTING.md, types/ directory is for shared types used by both
frontend (static/) and backend (lib/). Since AssemblySyntax is
frontend-only, it belongs in static/.
Also removed syntax tracking from device-view entirely:
- Device assembly (CUDA PTX, GPU, etc.) doesn't have Intel/AT&T variants
- device-view was storing syntax as immutable state that never updated
- This would cause incorrect tooltips if user toggled syntax after
opening
- Reverted device-view to match main branch (no syntax support)
Changes:
- Moved types/assembly-syntax.ts -> static/assembly-syntax.ts
- Updated import paths in compiler.ts
- Removed syntax field and imports from device-view.ts/.interfaces.ts
This means no unit tests are required per CONTRIBUTING.md guidelines
(tests only required for server-side components in lib/).
<!-- 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!
-->
Adds TheFusedKernelLibrary Beta-0.1.9 support for both C++ and CUDA
compilers.
This PR supersedes #8035 (cherry-picked and rebased to resolve conflicts
with main).
Original contribution by @morousg - thank you!
## Changes
- Added TheFusedKernelLibrary Beta-0.1.9 for C++ compilers
- Added TheFusedKernelLibrary Beta-0.1.9 for CUDA compilers
- Added contributor to CONTRIBUTORS.md
- Library placed in correct alphabetic order in libs list
Co-authored-by: Oscar Amoros Huguet <morousg@users.noreply.github.com>
<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>
Proposing to add the B-MPI3 library to the live site.
https://gitlab.com/correaa/boost-mpi3
Followed the steps as best as I could in based on other gitlab type
libraries (bmulti)
Feedback on improving the hooks and the organizations of files in the
repository is welcome.
The goal is to include the library by doing
#include<mpi3/communicator.hpp>.
This PR adds support for the Mojo programming language.
Explicitly tested viewing the generated assembly, LLVM IR, and running
the generated executable.
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>
[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>
<!-- 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!
-->
Hello all, I've added assembly documentation for the PowerPC platform
with this PR.
There's a couple of notes to keep in mind, mostly regarding automatic
processing:
1. Unfortunately, IBM made their documentation site very difficult to
automatically scrape. It uses dynamic rendering with a documentation API
that's protected by cookies, requiring the use of Selenium to scrape it.
2. While it is possible to scrape the documentation pages, it's
maddeningly difficult to do so, because the structure of the pages is
not guaranteed.
- Some pages have invisible elements in their headers that make matching
elements very difficult.
- Some pages are missing entire sections.
- Some pages are written without an introduction for the instruction
mnemonic, making the resulting documentation impossible to understand.
- Some pages, specifically for instructions without arguments, are
missing the table that lists the mnemonics out in order.
- I could go on, but I abandoned trying to do automatic processing after
running into this many roadblocks.
3. The automatic processing script is available in the docenizers
directory, but since it's not complete, feel free to ask to remove it.
4. I couldn't test the actual mnemonics appearing the editor, because my
local test setup kept trying to map the PowerPC instructions into AMD64
documentation, with predictably unusual results.
5. I didn't include AltiVec instructions, because there isn't any
webpage that documents them; they are only documented in a PDF file
provided by NXP.
Please let me know if there's anything else I need to do for this to
work. Thank you so much for your wonderful service!
Adds a new theme based on the One Dark theme from the Atom text editor.
Adds a new line highlighting theme "Soft Dark Rainbow" that works better
with the One Dark theme.
This patch makes a small change in how functions are handled while
parsing LLVM opt pipeline output. Specifically, it differentiates
between IR function and machine function, and while checking for the
close of function, it only checks if the corresponding function is open.
This was needed because in some targets like hexagon, the machine
functions could contain `BUNDLE`s as part of the dump and `BUNDLE`s are
also represented with opening and closing braces ({}). This was causing
assertion because the close brace for a BUNDLE was considered to be a IR
function close statement.
While reading the (excellent) documentation here, I noticed a few stale
references to `.js` files that are now implemented in TypeScript.
* Update `*.js` to `*.ts` in Markdown documentation.
* Update `app.js` to `out/dist/app.js` in
`docs/SystemdSocketActivation.md`.
_I managed to follow these instructions and locally run Compiler
Explorer through socket activation after that change._
* Update `*.js` to `*.ts` in the GitHub labeller config
`.github/labeler.yml`.
_Also correct some misnamed files here. I have checked the new version
with `ls $(grep -E "^ - " .github/labeler.yml | sed "s/ - //g")`. If I
were more familiar here, I would have liked to add a similar check to
the automated tests._
- Sheepishly add myself to the contributors list, despite this being a
tiny find-and-replace change.
---------
Co-authored-by: Jeremy Rifkin <51220084+jeremy-rifkin@users.noreply.github.com>
V (`vlang`) is a simple, fast and safe general purpose programming
language compiling to human-readable C.
#### Key features of V:
- simplicity, "only one way to do things"
- performance as fast as C
- safety: no null, no globals, no undefined behavior, immutability
- automatic C to V translation, good C interoperability
- hot code reloading
- flexible memory management (GC by default, manual, arena allocation,
autofree)
- other compilation backends like JavaScript, `native` (wip), `wasm`
(wip) or interpreted
#### Links:
Source code: https://github.com/vlang/v
Official website: https://vlang.io
Web playground: https://play.vlang.io/
infra PR: https://github.com/compiler-explorer/infra/pull/1058
#### Things this PR adds:
- General support for V
- Code inspection for the C, Go and JavaScript backends
- Support for the v formatter `v fmt`
- Some V example code
#### Things not implemented:
- Support for binary-output backends like `native` and `wasm`
- Support for running programs
<!-- 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!
-->
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
# Language name
Snowball 🐱
Language version
Snowball v0.0.7-beta
## Language homepage
Soon™️
Not the websites but some (WIP) documentation:
https://snowball-lang.gitbook.io/docs/
Compiler homepage
https://github.com/snowball-lang/snowball
Compiler version
v0.0.7-beta
Motivation
With a myriad of features to offer, Snowball boasts object-oriented
programming, memory safety, built-in functions for enhanced
productivity, and faster execution than other languages. Plus, its
garbage collector and unit testing make it a comprehensive tool for
developers.
> It's still in development but it's development is fast
This patch specifies path to GCC toolchain for those ancient Clang
versions. Ancient Clang versions are still very useful when revisiting
equally ancient bug reports, or figuring out when an ancient C or C++
defect report was implemented.
Note that modern spelling of this option is `--gcc-toolchain=`, which is
used for Clang 3.4 onwards, but those ancient versions has it in a
slightly different form.
Co-authored-by: Vlad Serebrennikov <serebrennnikov.vladislav@gmail.com>
Related to: https://github.com/compiler-explorer/infra/pull/1017
C3 is a system programming language based on C. It is an evolution of C
enabling the same paradigms and retaining the same syntax as far as
possible.
Design Principles:
Procedural "get things done"-type of language.
Try to stay close to C - only change what's really necessary.
C ABI compatibility and excellent C integration.
Learning C3 should be easy for a C programmer.
Data is inert.
Avoid "big ideas" & the "more is better" fallacy.
Introduce some higher level conveniences where the value is great.
You can try it out live on its tutorial website:
https://www.learn-c3.org
Source code: https://github.com/c3lang/c3c
---------
Co-authored-by: Rubén Rincón Blanco <git@rinconblanco.es>
- Update the actions in the GitHub Actions workflows to their latest versions.
- Run the workflows on the latest versions of the platforms where appropriate.
- Set the `check-latest` field of the `actions/setup-node` action to `true` to use the latest release of the specified Node.js version instead of using the cached one when there's a new release available.
- Explicitly specify the action versions instead of using the `latest` tag.
* Add ROCm Clang and HIP to CUDA
* Always include hip/hip_runtime.h
The need to include <hip/hip_runtime.h> and/or <hip/hip_runtime_api.h>
in HIP code before using HIP features is one big difference between
HIP and CUDA. Manually adding it to the command-line here is not ideal,
but the alternative is that the CUDA sample code will be broken by
default when a HIP compiler is selected.
This is perhaps an argument for making HIP a separate language in
compiler explorer, but there's pros and cons to both approaches. I'm
not sure which approach is best, but the existing HIP support that I
built upon was based on using CUDA as the language.
* Add hip-amd to CUDA libs
* Fix id collsion and drop --offload-arch
* Drop trunk compilers
The nightly builds of ROCm Clang and vanilla Clang lack both device
libraries and the HIP library. Their ability to compile HIP code is
very limited without those, to the extent that they will not be able
to build the example code without changes.
I suspect that it's possible to fix those issues, but it may be less
confusing to drop them from the compiler list until they are fully
functional.
* Add self to CONTRIBUTORS.md
* Restore hiptrunk compiler
Put the hiptrunk compiler back how it was, so that the addition of the
HIP libraries is a purely additive change in functionality. However,
mark hiptrunk as hidden so that it is not visible by default.
Co-authored-by: Patrick Quist <partouf@gmail.com>
