doc: Update gccgo information for recent changes.

R=r
CC=golang-dev
https://golang.org/cl/1941052

doc/gccgo_install.html

@@ -224,12 +224,9 @@ gccgo -o main main.o mypackage.o   # Explicitly links with mypackage.o
 
 <p>
 Some Go features are not yet implemented in <code>gccgo</code>.  As of
-2009-11-06, the following are not implemented:
+2010-08-23, the following are not implemented:
 
 <ul>
-<li>Garbage collection is not implemented. There is no way to free memory.
-    Thus long running programs are not supported.
-
 <li>goroutines are implemented as NPTL threads.  If you can not use
     the gold linker as described above, they are created with a fixed
     stack size, and the number of goroutines that may be created at
@@ -263,14 +260,13 @@ Pointers in Go are pointers in C. A Go <code>struct</code> is the same as C
 <code>struct</code> with the same fields and types.
 
 <p>
-The Go <code>string</code> type is a pointer to a structure.
-The current definition is
-(this is <b style="color: red;">expected to change</b>):
+The Go <code>string</code> type is currently defined as a two-element
+structure (this is <b style="color: red;">subject to change</b>):
 
 <pre>
 struct __go_string {
-  size_t __length;
-  unsigned char __data[];
+  const unsigned char *__data;
+  int __length;
 };
 </pre>
 
@@ -310,9 +306,10 @@ when the functions have equivalent types.
 
 <p>
 Go <code>interface</code>, <code>channel</code>, and <code>map</code>
-types have no corresponding C type (they roughly correspond to pointers
-to structs in C, but the structs are deliberately undocumented). C
-<code>enum</code> types correspond to some Go type, but precisely
+types have no corresponding C type (<code>interface</code> is a
+two-element struct and <code>channel</code> and <code>map</code> are
+pointers to structs in C, but the structs are deliberately undocumented). C
+<code>enum</code> types correspond to some integer type, but precisely
 which one is difficult to predict in general; use a cast. C <code>union</code>
 types have no corresponding Go type. C <code>struct</code> types containing
 bitfields have no corresponding Go type. C++ <code>class</code> types have
@@ -359,12 +356,15 @@ i := c_open(&amp;name[0], os.O_RDONLY, 0);
 <p>
 The name of Go functions accessed from C is subject to change. At present
 the name of a Go function that does not have a receiver is
-<code>package.Functionname</code>. To call it from C you must set the
-name using a <code>gcc</code> extension similar to the <code>gccgo</code>
+<code>prefix.package.Functionname</code>. The prefix is set by
+the <code>-fgo-prefix</code> option used when the package is compiled;
+if the option is not used, the default is simply <code>go</code>.
+To call the function from C you must set the name using
+a <code>gcc</code> extension similar to the <code>gccgo</code>
 extension.
 
 <pre>
-extern int go_function(int) __asm__ ("mypackage.Function");
+extern int go_function(int) __asm__ ("myprefix.mypackage.Function");
 </pre>
 
 <h3 id="Automatic_generation_of_Go_declarations_from_C_source_code">

doc/go_spec.html

@@ -5150,8 +5150,4 @@ The following minimal alignment properties are guaranteed:
 	<li><span class="alert">Implementation does not honor the restriction on goto statements and targets (no intervening declarations).</span></li>
 	<li><span class="alert">Method expressions are partially implemented.</span></li>
 	<li><span class="alert">Gccgo: allows only one init() function per source file.</span></li>
-	<li><span class="alert">Gccgo: Deferred functions cannot access the surrounding function's result parameters.</span></li>
-	<li><span class="alert">Gccgo: Function results are not addressable.</span></li>
-	<li><span class="alert">Gccgo: Recover is not implemented.</span></li>
-	<li><span class="alert">Gccgo: The implemented version of panic differs from its specification.</span></li>
 </ul>