Run compilers interactively from your web browser and interact with the assembly
JavaScript Assembly HTML CSS Python Makefile Other
Clone or download
Permalink
Failed to load latest commit information.
.idea First attempt at some new caching; including in-memory, on-disk, and … May 18, 2018
c-preload temporary use wine vcruntime until native vcruntime is installed Jan 4, 2018
d Update yarn.lock + d/.gitignore Jun 15, 2018
docs Add some documentation on privacy Jul 15, 2018
etc Use `-I` with ARM compilers. See #989 Jul 16, 2018
examples First stab at CUDA support. See #221 May 7, 2018
haskell New attempt at running the haskell demangler Oct 26, 2017
lib Remove final traces of FullStory Jul 15, 2018
rust Update rustfilt dependencies to support demangling on macOS Jul 15, 2018
static Fix new share buttons style on dark theme Jul 19, 2018
test Merge branch 'master' into EU Jul 15, 2018
views Address some PR comments Jul 11, 2018
.eslintignore Move to ESLint Feb 13, 2018
.eslintrc Enforce max-statement/line & further unify UI Mar 24, 2018
.gitattributes Attempt two at specifying linguist config Feb 17, 2018
.gitignore Use a local-installed yarn. Refactor all the 'find node' stuff out of… Feb 10, 2018
.istanbul.yml Separate compiler search from app.js Apr 12, 2018
.travis.yml Test automatic Travis changelog creation Mar 26, 2018
AUTHORS.md * Added "Analysis" pseudo-language which lets arbitrary text be analy… May 5, 2018
CODEOWNERS Improve small details Apr 12, 2018
CODE_OF_CONDUCT.md Improve docs (Wording & raw and stylized visuals) Mar 19, 2018
CONTRIBUTING.md Fix missing contributing sentence Mar 22, 2018
CONTRIBUTORS.md Reestructure static with new views and mode dirs Jul 16, 2018
LICENSE New year, new date Jan 1, 2018
Makefile Handle moved policies Jul 14, 2018
PULL_REQUEST_TEMPLATE.md Fix PULL_REQUEST_TEMPLATE.md comment tag Jun 14, 2018
README.md Create CONTRIBUTORS.md Jun 8, 2018
Roadmap.md Updated roadmap Apr 23, 2018
app.build.js Don't attempt to pack monaco-editor. Jan 15, 2017
app.js Merge branch 'master' into EU Jul 14, 2018
package.json Set solid bases for cookie and privacy control Jul 4, 2018
webpack.config.js Fix bad require path Jul 17, 2018
yarn.lock Set solid bases for cookie and privacy control Jul 4, 2018

README.md

Build Status codecov

Compiler Explorer

Compiler Explorer

Compiler Explorer is an interactive compiler. The left-hand pane shows editable C, C++, Rust, Go, D, Haskell, Swift and Pascal code. The right, the assembly output of having compiled the code with a given compiler and settings. Multiple compilers are supported, and the UI layout is configurable (thanks to GoldenLayout). There is also an ispc compiler ? for a C variant with extensions for SPMD.

Try out at godbolt.org

You can support this project on Patreon.

Compiler Explorer follows a Code of Conduct which aims to foster an open and welcoming environment.

Contact us

For general discussion, please join the mailing list at https://groups.google.com/forum/#!forum/compiler-explorer-discussion or the cpplang slack channel #compiler_explorer.

If you are interested in developing, or want to see the discussions between existing developers, feel free to join the mailing list at https://groups.google.com/forum/#!forum/compiler-explorer-development or the cpplang slack channel #ce_implementation.

Feel free to raise an issue on github or email Matt directly for more help.

Developing

Compiler Explorer is written in Node.js.

Assuming you have a compatible version of node installed, simply running make ought to get you up and running with an Explorer running on port 10240 on your local machine: http://localhost:10240/. Currently Compiler Explorer requires the latest LTS node version (v8) installed, either on the path or at NODE_DIR (an environment variable or make parameter).

Running with make EXTRA_ARGS='--language LANG' will allow you to load LANG exclusively, where LANG is one for the language ids/aliases defined in lib/languages.js. The Makefile will automatically install all the third party libraries needed to run; using yarn to install server-side and client side components.

The config system leaves a lot to be desired. Work has been done on porting CCS to Javascript and then something more rational can be used.

A Road map is available which gives a little insight into the future plans for Compiler Explorer.

Running a local instance

If you want to point it at your own GCC or similar binaries, either edit the etc/config/LANG.defaults.properties or else make a new one with the name LANG.local.properties, subsituting LANG as needed. *.local.properties files have the highest priority when loading properties.

When running in a corporate setting the URL shortening service can be replaced by an internal one to avoid leaking source code outside of the organization. This is done by adding a new module in static/urlshorten-myservice.js and setting the urlShortenService variable in configuration. This module should export a single function, see the google module for an example. urlShortenService can also be set to none to disable url shortening altogether.

RESTful API

There's a simple restful API that can be used to do compiles to asm and to list compilers. In general all handlers live in /api/* endpoints, will accept JSON or text in POSTs, and will return text or JSON responses depending on the request's Accept header.

At a later date there may be some form of rate-limiting: currently, requests will be queued and dealt with in the same way interactive requests are done for the main site. Authentication might be required at some point in the future (for the main Compiler Explorer site anyway).

The following endpoints are defined:

GET /api/languages - return a list of languages

Returns a list of the currently supported languages, as pairs of languages IDs and their names.

GET /api/compilers - return a list of compilers

Returns a list of compilers. In text form, there's a simple formatting of the ID of the compiler, its description and its language ID. In JSON, all the information is returned as an array of compilers, with the id key being the primary identifier of each compiler.

GET /api/compilers/<language-id> - return a list of compilers with matching language

Returns a list of compilers for the provided language id. In text form, there's a simple formatting of the ID of the compiler, its description and its language ID. In JSON, all the information is returned as an array of compilers, with the id key being the primary identifier of each compiler.

POST /api/compiler/<compiler-id>/compile - perform a compilation

To specify a compilation request as a JSON document, post it as the appropriate type and send an object of the form:

{
    "source": "Source to compile",
    "options": {
        "userArguments": "Compiler flags",
        "compilerOptions": {},
        "filters": {
            "filter": true
        }
    }
}

The filters are a JSON object with true/false values. If not supplied, defaults are used. If supplied, the filters are used as-is. The compilerOptions is used to pass extra arguments to the back end, and is probably not useful for most REST users.

A text compilation request has the source as the body of the post, and uses query parameters to pass the options and filters. Filters are supplied as a comma-separated string. Use the query parameter filters=XX to set the filters directly, else addFilters=XX to add a filter to defaults, or removeFilters to remove from defaults. Compiler parameters should be passed as options=-O2 and default to empty.

Filters include binary, labels, intel, comments, directives and demangle, which correspond to the UI buttons on the HTML version.

The text request is designed for simplicity for command-line clients like curl

$ curl 'https://godbolt.org/api/compiler/g63/compile?options=-Wall' --data-binary 'int foo() { return 1; }'
# Compilation provided by Compiler Explorer at godbolt.org
foo():
        push    rbp
        mov     rbp, rsp
        mov     eax, 1
        pop     rbp
        ret

If JSON is present in the request's Accept header, the compilation results are of the form:

(Optional values are marked with a **)

{
  "code": 0 if successful, else compiler return code,
  "stdout": [
            {
              "text": Output,
              ** "tag": {
                          "line": Source line,
                          "text": Parsed error for that line
                 }
            },
            ...
  ],
  "stderr": (format is similar to that of stdout),
  "asm": [
         {
           "text": Assembly text,
           "source": {file: null for user input, else path, line: number} or null if none
         },
         ...
  ],
  "okToCache": true if output could be locally cached else false,
  ** "optOutput" : {
                     "displayString" : String displayed in output,
                     "Pass" : [ Missed | Passed | Analysis ] (Specifies the type of optimisation output),
                     "Name" : Name of the output (mostly represents the reason for the output),
                     "DebugLoc" : {
                        "File": Name of file,
                        "Line": Line number,
                        "Column": Column number in line
                     },
                     "Function": Name of function for which optimisation output is provided,
                     "Args": Array of objects representing the arguments that the optimiser used when trying to optimise
     }
}

Credits

Compiler Explorer is maintained by the awesome people listed in the AUTHORS file.

We would like to thank the contributors listed in the CONTRIBUTORS file, who have helped shape Compiler Explorer.

We would also like to specially thank these people for their contributions to Compiler Explorer:

We would like to thank JetBrains for their support and for donating licenses to their excellent products to develop Compiler Explorer.

JetBrains