Check in a pristine copy of GCC 4.8.1.

The copy of GCC that we use for Android is still not working for
mingw. Rather than finding all the differences that have crept into
our GCC, just check in a copy from
ftp://ftp.gnu.org/gnu/gcc/gcc-4.9.3/gcc-4.8.1.tar.bz2.

GCC 4.8.1 was chosen because it is what we have been using for mingw
thus far, and the emulator doesn't yet work when upgrading to 4.9.

Bug: http://b/26523949
Change-Id: Iedc0f05243d4332cc27ccd46b8a4b203c88dcaa3

1 files changed, 76 insertions, 0 deletions

diff --git a/gcc-4.8.1/libjava/classpath/TODO b/gcc-4.8.1/libjava/classpath/TODO
new file mode 100644
index 000000000..df7eed7d0
--- /dev/null
+++ b/gcc-4.8.1/libjava/classpath/TODO
@@ -0,0 +1,76 @@
+See also http://www.gnu.org/software/classpath/tasks.html
+Which is updated more often then this file.
+
+The Classpath TODO list as of 2002/05/05
+
+-- Write Mauve (http://sourceware.cygnus.com/mauve/) tests for those
+   classes that don't have them.
+
+-- Write Java 2 packages not currently included or improve existing 
+   ones.
+
+-- Modify ClassLoader.getSystemResource() to support loading classes 
+   from zip files in the CLASSPATH.  This requires java.util.zip to
+   be integrated first.  Jar files can probably be treated as zip
+   files for now.
+
+-- Continue comparison and merge of classes between Classpath and GCJ.
+
+   Current status: http://gcc.gnu.org/java/libgcj-classpath-compare.html
+
+   Please keep in mind that Red Hat wishes to continue to use CNI
+   as their preferred native interface.  See:
+
+   http://sourceware.cygnus.com/java/papers/cni/t1.html
+
+-- No resolution was identified for generating JNI compatible code from 
+   CNI source.  The simple solution has been adopted to include
+   both in GNU Classpath if and only if another JVM chooses to use CNI.  
+   Provisions for compiling CNI correctly need to be implemented.
+
+-- Update the GNU Classpath Hacker's Guide.  There is a master texinfo
+   file in the doc/ directory in Classpath CVS.
+
+-- Audit the code to identify methods that do not have Javadoc comments
+   and/or comments that are incomplete.  All input parameters, return
+   values, etc should be documentes.  Also look for Javadoc comments on
+   variables that are serializable.  
+   See http://java.sun.com/j2se/javadoc/writingdoccomments/index.html#tag 
+   for details of what should be where in comments.
+
+-- Figure out a way to generate a hardcopy manual for the Java class
+   library from the embedded Javadocs.  This probably involves writing
+   a custom doclet and probably some supplementary documentation
+   files into which the extracted Javadoc files are included.
+
+-- Audit the code to ensure that all variable declarations are consistent
+   with the "Serialized Form" in the JDK.  That is, all serialized
+   variables in the JDK should be included in Classpath and all Classpath
+   instance variables that are not part of the JDK docs should be marked
+   transient.  Please be sure to use the online version of the Javadocs
+   for this and do not accept any "clickwrap" licenses from Sun in order
+   to download the JDK 1.2 Javadocs, which is where this information is
+   stored.
+
+-- Audit code similar to above to determine where Sun uses readObject()
+   and writeObject() for serialization and determine what Classpath
+   needs to do for compatibility.
+
+-- Audit code to ensure that every class that should be serializable
+   actually implementst java.io.Serializable and has the correct
+   serialVersionUID private static variable that is identical to the
+   JDK 1.1 version.  You can obtain that variable value using the
+   serialver command.
+
+-- Do real life serialization compatibility tests of our code vs 
+   the JDK using serialcompat from Japitools.
+
+-- Audit code for thread safety. 
+
+-- Audit Java code for proper Security implementation.
+
+-- Audit native code for security, memory handling, etc.
+
+-- Bug reports are always welcome.  They are double welcome if they
+   are accompanied by a Mauve test that reproduces the bug.
+