## Introduction

These are some notes on contributing to the `gccgo` frontend for GCC. For information on contributing to parts of Go other than `gccgo`, see Contributing to the Go project. For information on building `gccgo` for yourself, see Setting up and using gccgo.

## Legal Prerequisites

You must follow the Go copyright rules.

## Code

The source code for the `gccgo` frontend may be found in the directory `gcc/go`. The frontend is written in C++ and as such the GNU coding standards do not entirely apply; in writing code for the frontend, follow the formatting of the surrounding code. Although the frontend is currently closely tied to the rest of the gcc codebase, we plan to make it more independent. Any new code which uses other parts of gcc should be segregated in an appropriate file, such as `gogo-tree.cc`.

The runtime library for `gccgo` is mostly the same as the library in the main Mercurial repository. The library code in the Mercurial repository is periodically copied into the `gccgo` repository. Accordingly, most library changes should be made in Mercurial. Changes to the few `gccgo` specific parts of the library should follow the process described here. The `gccgo` specific parts of the library are everything in the `libgo` directory except for the `libgo/go` subdirectory.

## Testing

All patches must be tested. There are two test suites. A patch that introduces new failures is not acceptable.

To run the compiler test suite, run `make check-go` in the `gcc` subdirectory of your build directory. This will run various tests underneath `gcc/testsuite/go.*`. This includes a copy of the tests in the Mercurial repository, which are run using the DejaGNU script found in in `gcc/testsuite/go.test/go-test.exp`. Many of the compiler tests may be run without the Go library, but some do require the library to built first.

To run the library test suite, run `make check-target-libgo` in the top level of your build directory.

Most new tests should be submitted to the Mercurial repository for copying into the `gccgo` repository. If there is a need for specific tests for `gccgo`, they should go in the `gcc/testsuite/go.go-torture` or `gcc/testsuite/go.dg` directories.

## Submitting Changes

Proposing a patch should follow the standard GCC rules. That is, the patch should be sent to the mailing list `gcc-patches@gcc.gnu.org` as a diff—the output of the `diff` program with the `-c` or `-u` option. In the future we are likely to set up a separate gccgo-specific mailing list, which should also be CC'ed; we will update this document at that time. Patch emails should include a ChangeLog entry, though the ChangeLog entry should not be in the diff itself. ChangeLog files are a standard part of GNU programs; see the GNU coding standards.