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

The gccgo frontend is part of the GCC compiler, and it follows the GCC contribution rules. In particular, for substantial patches—more than 10 lines—you must have a copyright assignment with the Free Software Foundation.

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.