| Commit message (Collapse) | Author | Age |
... | |
|
|
| |
With a small added ts'ification in base-compiler.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mindless replacements of the form
`_.filter(options, option =>...` --> `options.filter(option =>...`.
One not *entirely* mindless replacement at the bottom of
compiler-dropin-tool.ts :
```
- return _.filter(pathFilteredFlags) as string[];
+ return pathFilteredFlags.filter(Boolean) as string[];
```
6 files can now stop importing underscore.
|
|
|
|
|
| |
Seems I missed this one when doing PR #5700. This caused *some* of the
grief mentioned in the discussion of issue #5667, but certainly not all
of it.
|
|
|
|
|
| |
Following the discussion in #3864.
@RossSmyth FYI
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<!-- 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!
-->
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
# Cerberus
[Cerberus](https://www.cl.cam.ac.uk/~pes20/cerberus/) offers executable
semantics for a substantial fragment of C and
CHERI-C languages. It is implemented via an elaboration into a simpler
Core language, which is displayed as the compiler
output in the Compiler Explorer. Evaluation of C programs (execution) is
also supported.
## Prerequisites
The easiest way to install both the Cerberus and Cerberus-CHERI
compilers is by using Docker:
`docker pull vzaliva/cerberus-cheri`
Then, for example, you can print the _Core_ elaboration for `test.c`
using ISO C semantics:
`docker run -v $HOME/tmp:/mnt -it vzaliva/cerberus-cheri cerberus
--pp=core --exec /mnt/test.c`
## Configuration
The file `etc/config/c.defaults.properties` defines a group of two
compilers: 'cerberus' for ISO C and 'cerberus-cheri'
for CHERI-C. It assumes that the corresponding executables are in the
path.
## Limitations and Future Improvement
Presently, only simple Core output is shown. It is not syntactically
highlighted nor linked to C source code locations.
Some potential future improvements include:
1. Error location handling in warning and error messages
2. Specifying execution flags
3. Core syntax highlighting
4. Display of AST
5. Display of other intermediate languages (Cabs, Ail)
6. Tooltips/links to the ISO C document from Core annotations
## See also:
- [Cerberus (project page)](https://www.cl.cam.ac.uk/~pes20/cerberus/)
- [Cerberus (GitHub
repository)](https://github.com/rems-project/cerberus)
- ["Formal Mechanised Semantics of CHERI C: Capabilities, Undefined
Behaviour, and Provenance" (paper,
preprint)](https://zaliva.org/cheric-asplos24.pdf)
- ["CHERI C semantics as an extension of the ISO C17 standard" (tech
report)](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-988.html)
|
|
|
|
|
|
|
|
| |
Some operations set `exec`'s `maxOutput` to a value larger than the max
string length. This change ensures we always cap output to the engine's
string limit (currently 512 MB in recent Node versions).
This also tweaks handling when reaching the string limit to ensure
adding the "truncated" message itself does not send us beyond the limit.
|
|
|
|
| |
This allows each compiler to override the default Monaco language used
by the opt pipeline view.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a Racket optimisation pipeline view by reusing the existing
LLVM-focused optimisation pipeline UI. A Racket-specific pass parser
translates its output into passes for the UI to present.
This new Racket optimisation pipeline view is currently only enabled for
Racket nightly, as it depends on [recent
changes](https://github.com/racket/racket/pull/4842) to Racket's
compiler output to function.
This also extends the opt pipeline view to allow customising the
function selector label as well as the options and filters for each
compiler where needed.

---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
|
|
|
|
|
|
|
| |
* directory structure has changed
* no more releases of icc
Depends on deployment of
https://github.com/compiler-explorer/infra/pull/1188
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #5502
In this PR I make an early attempt to add the CMakeScript as a language
in compiler-explorer. I will be fantastic having this since CMake is one
of the most used build system. Having an cmake interpreter in the web
would probe truly useful for teams and individuals, it will be a
fantastic way to share snippets of cmakescript and show how they are
executed with different cmake versions.
Co-authored-by: Matt Godbolt <matt@godbolt.org>
|
|
|
|
|
|
|
|
|
|
| |
Adds D8Compiler, which applies to the Android Java and Android Kotlin
languages. D8Compiler instantiates a JavaCompiler or KotlinCompiler
using the java/kotlin dependencies' paths for D8 in the infra repo.
compiler-finder.ts has been updated to allow for duplicate compiler IDs
for 'android-java' and 'android-kotlin', as it is expected that the
compilers used for these languages is the same.
|
|
|
|
|
|
|
|
|
| |
This PR adds GIMPLE as a language

---------
Co-authored-by: Marc Poulhiès <dkm@kataplop.net>
|
|
|
|
|
|
|
|
|
|
|
| |
This prepares for future work that will reuse the opt pipeline view
outside of the LLVM ecosystem by renaming related components to remove
the LLVM prefix.
The pass dumper keep its LLVM prefix, as it is assumed this part is
likely to be customised for each compiler ecosystem.
The historical component name has been preserved in the component list
as an alias to keep old links working.
|
|\
| |
| |
| | |
https://github.com/compiler-explorer/compiler-explorer into main
|
| | |
|
|/ |
|
|
|
| |
Closes #5660
|
|
|
| |
c3c compiler version 0.5 (alpha) added.
|
| |
|
| |
|
| |
|
|
|
| |
And reformat everything.
|
| |
|
|
|
|
|
|
|
| |
Apparently AST for ldc is an abuse of terminology, as it doesn't
produces anything resembling a syntax tree:
https://github.com/dlang/dmd/pull/6556#issuecomment-282353400 . It is
potentially meaningful only to ldc developers. Anyway the `generateAST`
result type is fixed, along with some other small stuff around.
|
|
|
|
| |
Since .NET 8.0, the JIT disasm no longer prints encoded bytes of
instructions by default, so we can disable diffable asm by default.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A majority of the actions/backends expect to find certain classes and
definitions in the source code. There's no canonical reference for this
so it's a combination of incomplete docs and the actual uses in
llvm-project.
(most of the time I expect people will come from llvm-project to
experiment, rather than the other way around)
I've added an example that uses the Searchable Tables backend.
<!-- 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!
-->
|
| |
|
| |
|
| |
|
|
|
| |
prep for #5533 and #5644
|
|
|
|
|
|
|
|
|
| |
Since trunk will be a moving target, I've left the default compiler as
17.01.
The standard include path will allow for examples that include files
like `include "llvm/TableGen/SearchableTable.td"`, without extra
options. This is useful if you want to create a minimal example of the
records that an existing backend expects to see.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM TableGen is used to generate complex output files in the llvm
project. A generic description of classes and definitions produces
"records" that can then be walked by a TableGen backend to produce
things like C++ code, configuration files, etc.
The biggest examples are LLVM's assembler and disassembler where all the
targets' instructions are defined in TableGen.
https://llvm.org/docs/TableGen/ProgRef.html
An example:
```
class Register<int _size, string _alias=""> {
int size = _size;
string alias = _alias;
}
def X0: Register<8> {}
def X29: Register<8, "frame pointer"> {}
```
```
------------- Classes -----------------
class Register<int Register:_size = ?, string Register:_alias = ""> {
int size = Register:_size;
string alias = Register:_alias;
}
------------- Defs -----------------
def X0 { // Register
int size = 8;
string alias = "";
}
def X29 { // Register
int size = 8;
string alias = "frame pointer";
}
```
It's often a pain point for people new to LLVM so having a quick way to
experiment would be a great benefit for the community (we have a Jupyter
kernel which is good but not as simple as Compiler Explorer).
The compiler for TableGen is `llvm-tblgen`. This comes with most release
builds of LLVM in /bin along with clang and the others. Its default is
to output a text dump of the records defined so that's what I've used
here. This is not executable code so I've disabled the features related
to that.
A user could pass options to `llvm-tblgen` to produce text in a format
other than this, C++ code or JSON for example. However this text dump is
the main use case.
I've re-used an existing clang install, since that includes
`llvm-tblgen` in `bin/`. I just added the 17.01 version for this first
change.
Syntax highlighting is a mix of the Fortran and Ada configuration,
following the language spec I linked above. Though I am very new to that
so it is likely incomplete.
|
|
|
|
| |
When we see JitDisasmDiffable being set manually, we can stop
automatically emitting JitDisasmDiffable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<!-- 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!
-->
Since DXC is a fork of Clang from LLVM 3.7, the AST can be generated and
parsed in a manner similar to the Clang AST.
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
This PR adds front end support for the
[Hylo](https://www.hylo-lang.org/) programming language. Back end
support has already been added with
https://github.com/compiler-explorer/misc-builder/pull/71 and
https://github.com/compiler-explorer/misc-builder/pull/72.
|
| |
| |
| |
| |
| |
| | |
Crystal 1.9+ has made the `.s` and `.ll` files follow the base name of
the output rather than the input (I think this is due to
crystal-lang/crystal#13370), this PR matches the Crystal compiler's
behavior
|
| |
| |
| |
| | |
when we emit intel
|
| | |
|
| | |
|
| | |
|