doc: update gccgo docs for move of gofrontend to git

This also includes some other minor updates to the documentation.

Change-Id: Iafab353727d7622d125b97fbdeaa81525b7a92aa
Reviewed-on: https://go-review.googlesource.com/11123
Reviewed-by: Yves Junqueira <yves.junqueira@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>

doc/gccgo_contribute.html

@@ -30,7 +30,9 @@ contribution rules</a>.
 
 <p>
 The master sources for the gccgo frontend may be found at
-<a href="//code.google.com/p/gofrontend">http://code.google.com/p/gofrontend</a>.
+<a href="http://go.googlesource.com/gofrontend">http://go.googlesource.com/gofrontend</a>.
+They are mirrored
+at <a href="http://github.com/golang/gofrontend">http://github.com/golang/gofrontend</a>.
 The master sources are not buildable by themselves, but only in
 conjunction with GCC (in the future, other compilers may be
 supported).  Changes made to the gccgo frontend are also applied to
@@ -53,14 +55,12 @@ them.
 </p>
 
 <p>
-The gccgo frontend is written in C++.  It follows the GNU coding
-standards to the extent that they apply to C++.  In writing code for
-the frontend, follow the formatting of the surrounding code.  Although
-the frontend is currently tied to the rest of the GCC codebase, we
-plan to make it more independent.  Eventually all GCC-specific code
-will migrate out of the frontend proper and into GCC proper.  In the
-GCC sources this will generally mean moving code
-from <code>gcc/go/gofrontend</code> to <code>gcc/go</code>.
+The gccgo frontend is written in C++.
+It follows the GNU and GCC coding standards for C++.
+In writing code for the frontend, follow the formatting of the
+surrounding code.
+Almost all GCC-specific code is not in the frontend proper and is
+instead in the GCC sources in the <code>gcc/go</code> directory.
 </p>
 
 <p>

doc/gccgo_install.html

@@ -46,6 +46,12 @@ identical to Go 1.1.  The GCC 4.8.2 release includes a complete Go
 The GCC 4.9 releases include a complete Go 1.2 implementation.
 </p>
 
+<p>
+The GCC 5 releases include a complete implementation of the Go 1.4
+user libraries.  The Go 1.4 runtime is not fully merged, but that
+should not be visible to Go programs.
+</p>
+
 <h2 id="Source_code">Source code</h2>
 
 <p>
@@ -174,13 +180,10 @@ export LIBRARY_PATH C_INCLUDE_PATH CPLUS_INCLUDE_PATH
 <h2 id="Using_gccgo">Using gccgo</h2>
 
 <p>
-The gccgo compiler works like other gcc frontends.  The gccgo
-installation does not currently include a version of
-the <code>go</code> command.  However if you have the <code>go</code>
-command from an installation of the <code>gc</code> compiler, you can
-use it with gccgo by passing the option <code>-compiler gccgo</code>
-to <code>go build</code> or <code>go install</code> or <code>go
-test</code>.
+The gccgo compiler works like other gcc frontends.  As of GCC 5 the gccgo
+installation also includes a version of the <code>go</code> command,
+which may be used to build Go programs as described at
+<a href="http://golang.org/cmd/go">http://golang.org/cmd/go</a>.
 </p>
 
 <p>
@@ -232,13 +235,14 @@ name the directory where <code>libgo.so</code> is found.
 
 <li>
 <p>
-Passing a <code>-Wl,-R</code> option when you link:
+Passing a <code>-Wl,-R</code> option when you link (replace lib with
+lib64 if appropriate for your system):
 </p>
 
 <pre>
-gccgo -o file file.o -Wl,-R,${prefix}/lib/gcc/MACHINE/VERSION
+go build -gccgoflags -Wl,-R,${prefix}/lib/gcc/MACHINE/VERSION
 [or]
-gccgo -o file file.o -Wl,-R,${prefix}/lib64/gcc/MACHINE/VERSION
+gccgo -o file file.o -Wl,-R,${prefix}/lib/gcc/MACHINE/VERSION
 </pre>
 </li>
 
@@ -266,27 +270,33 @@ and <code>-g</code> options.
 </p>
 
 <p>
-The <code>-fgo-prefix=PREFIX</code> 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 <code>PREFIX</code> may be any string; a good choice for the
-string is the directory where the package will be installed.
+The <code>-fgo-pkgpath=PKGPATH</code> option may be used to set a
+unique prefix for the package being compiled.
+This option is automatically used by the go command, but you may want
+to use it if you invoke gccgo directly.
+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 <code>PKGPATH</code> may be any string; a good choice for the
+string is the path used to import the package.
 </p>
 
 <p>
 The <code>-I</code> and <code>-L</code> options, which are synonyms
 for the compiler, may be used to set the search path for finding
 imports.
+These options are not needed if you build with the go command.
 </p>
 
 <h2 id="Imports">Imports</h2>
 
 <p>
 When you compile a file that exports something, the export
-information will be stored directly in the object file.  When
-you import a package, you must tell gccgo how to
-find the file.
+information will be stored directly in the object file.
+If you build with gccgo directly, rather than with the go command,
+then when you import a package, you must tell gccgo how to find the
+file.
+</p>
 
 <p>
 When you import the package <var>FILE</var> with gccgo,
@@ -319,9 +329,10 @@ gccgo.  Both options take directories to search. The
 </p>
 
 <p>
-The gccgo compiler does not currently (2013-06-20) record
+The gccgo compiler does not currently (2015-06-15) record
 the file name of imported packages in the object file. You must
 arrange for the imported data to be linked into the program.
+Again, this is not necessary when building with the go command.
 </p>
 
 <pre>