-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 source code for the gccgo frontend may be found at
+http://code.google.com/p/gofrontend.
+Changes made to that project are routinely merged into the source code
+hosted at gcc.gnu.org. The gofrontend
+project includes only the Go frontend proper. These are the files
+which in the gcc sources may be found in the
+directories gcc/go and libgo.
+The gcc sources also include a copy of
+the test directory
+from the main Go repository.
+
+
+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 that uses other
+parts of gcc should be placed in an appropriate file,
+such as gogo-tree.cc. Eventually
+all gcc-specific code should migrate to
+a gcc-interface subdirectory.
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.
+library in the main Go
+repository. The library code in the Go repository is periodically
+copied into the gofrontend and the gcc
+repositories. Accordingly, most library changes should be made in the
+main Go repository. 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.
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
+includes a copy of the tests in the main Go 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.
@@ -67,25 +81,19 @@ check-target-libgo in the top level of your build directory.
-Most new tests should be submitted to the Mercurial repository for
+Most new tests should be submitted to the main Go 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.
+or gcc/testsuite/go.dg directories in
+the gcc.gnu.org repository.
-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.
+Changes to the Go frontend should follow the same process as for the
+main Go repository, only for the gofrontend project
+rather than the go project. Those changes will then be
+merged into the gcc sources.
gcc code
repository: svn://gcc.gnu.org/svn/gcc/branches/gccgo.
+
+Note that although gcc.gnu.org is the most convenient way
+to get the source code for the compiler, that is not where the master
+sources live. If you want to contribute changes to the gccgo
+compiler, see Contributing to
+gccgo.
+
@@ -139,6 +148,32 @@ future the requirement of explicitly specifying may be removed. +
+The gccgo compiler supports all gcc options
+that are language independent, notably the -O
+and -g options.
+
+
+The -fgo-prefix=PREFIX option may be used to set a unique
+prefix for the package being compiled. This option is intended for
+use with large programs that contain many packages, in order to allow
+multiple packages to use the same identifier as the package name.
+The PREFIX may be any string; a good choice for the
+string is the directory where the package will be installed.
+
+
+The -fno-require-return-statement option may be used to
+disable the compiler error about functions missing return statements.
+Note that there is no way to disable this error in 6g.
+
+
+The -I and -L options, which are synonyms
+for the compiler, may be used to set the search path for finding
+imports.
+
+
@@ -195,8 +230,10 @@ Some Go features are not yet implemented in gccgo. As of