Add the full crosstool-NG sources to the new repository of its own.

You might just say: 'Yeah! crosstool-NG's got its own repo!".
Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup.
That means I'm putting backups in place in the afternoon.
That also means we've lost history... :-(

3 files changed, 264 insertions, 0 deletions

diff --git a/patches/gcc/4.0.1/fix-fixincl.patch b/patches/gcc/4.0.1/fix-fixincl.patch
new file mode 100644
index 0000000..8051f31
--- /dev/null
+++ b/patches/gcc/4.0.1/fix-fixincl.patch
@@ -0,0 +1,72 @@
+See http://gcc.gnu.org/PR22541
+
+From: Dan Kegel
+
+When building gcc-3.4.3 or gcc-4.0.[01] into a clean $PREFIX (the only two I've tried like this),
+the configure script happily copies the glibc include files from include to sys-include;
+here's the line from the log file (with $PREFIX instead of the real prefix):
+
+Copying $PREFIX/i686-unknown-linux-gnu/include to $PREFIX/i686-unknown-linux-gnu/sys-include
+
+But later, when running fixincludes, it gives the error message
+ The directory that should contain system headers does not exist:
+  $PREFIX/lib/gcc/i686-unknown-linux-gnu/3.4.3/../../../../i686-unknown-linux-gnu/sys-include
+
+Nevertheless, it continues building; the header files it installs in
+ $PREFIX/lib/gcc/i686-unknown-linux-gnu/3.4.3/include
+do not include the boilerplate that would cause it to #include_next the
+glibc headers in the system header directory.
+Thus the resulting toolchain can't compile the following program:
+#include <limits.h>
+int x = PATH_MAX;
+because its limits.h doesn't include the glibc header.
+
+That's not nice.  I suspect the problem is that gcc/Makefile.in assumes that
+it can refer to $PREFIX/i686-unknown-linux-gnu  with the path 
+                $PREFIX/lib/../i686-unknown-linux-gnu, but
+that fails because the directory $PREFIX/lib doesn't exist during 'make all';
+it is only created later, during 'make install'.  (Which makes this problem
+confusing, since one only notices the breakage well after 'make install',
+at which point the path configure complained about does exist, and has the
+right stuff in it.)
+
+A possible fix is to replace the line in gcc/Makefile.in that says
+    SYSTEM_HEADER_DIR = @SYSTEM_HEADER_DIR@
+with a version that gets rid of extra ..'s, e.g.
+    SYSTEM_HEADER_DIR = `echo @SYSTEM_HEADER_DIR@ | sed -e :a -e "s,[^/]*/\.\.\/,,;ta"`
+(hey, that's the first time I've ever used a label in a sed script; thanks to the sed faq
+for explaining the :a ... ta method of looping to repeat a search-and-replace until it doesn't match.)
+
+[rediffed against gcc-4.0.0]
+
+--- gcc-4.0.0/gcc/Makefile.in.orig	2005-04-04 12:45:13.000000000 -0700
++++ gcc-4.0.0/gcc/Makefile.in	2005-05-20 12:33:43.000000000 -0700
+@@ -378,7 +378,10 @@
+ CROSS_SYSTEM_HEADER_DIR = @CROSS_SYSTEM_HEADER_DIR@
+ 
+ # autoconf sets SYSTEM_HEADER_DIR to one of the above.
+-SYSTEM_HEADER_DIR = @SYSTEM_HEADER_DIR@
++# Purge it of unneccessary internal relative paths
++# to directories that might not exist yet.
++# The sed idiom for this is to repeat the search-and-replace until it doesn't match, using :a ... ta.
++SYSTEM_HEADER_DIR = `echo @SYSTEM_HEADER_DIR@ | sed -e :a -e "s,[^/]*/\.\.\/,," -e ta`
+ 
+ # Control whether to run fixproto and fixincludes.
+ STMP_FIXPROTO = @STMP_FIXPROTO@
+@@ -2838,13 +2841,15 @@
+ ../$(build_subdir)/fixincludes/fixincl: ; @ :
+ 
+ # Build fixed copies of system files.
++# Abort if no system headers available, unless building a crosscompiler.
++# FIXME: abort unless building --without-headers would be more accurate and less ugly
+ stmp-fixinc: gsyslimits.h macro_list \
+   ../$(build_subdir)/fixincludes/fixincl \
+   ../$(build_subdir)/fixincludes/fixinc.sh
+ 	@if test ! -d ${SYSTEM_HEADER_DIR}; then \
+ 	  echo The directory that should contain system headers does not exist: >&2 ; \
+ 	  echo "  ${SYSTEM_HEADER_DIR}" >&2 ; \
+-	  if test "x${SYSTEM_HEADER_DIR}" = "x${gcc_tooldir}/sys-include"; \
++	  if test "x${SYSTEM_HEADER_DIR}" = "x`echo "${gcc_tooldir}/sys-include" | sed -e :a -e "s,[^/]*/\.\.\/,," -e ta`"; \
+ 	  then sleep 1; else exit 1; fi; \
+ 	fi
+ 	rm -rf include; mkdir include
diff --git a/patches/gcc/4.0.1/pr20815-fix.patch b/patches/gcc/4.0.1/pr20815-fix.patch
new file mode 100644
index 0000000..7ac8ab5
--- /dev/null
+++ b/patches/gcc/4.0.1/pr20815-fix.patch
@@ -0,0 +1,121 @@
+Date: 18 May 2005 22:47:59 -0000
+Message-ID: <20050518224759.7352.qmail@sourceware.org>
+From: "hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org>
+To: dank@kegel.com
+References: <20050407215701.20815.dank@kegel.com>
+Reply-To: gcc-bugzilla@gcc.gnu.org
+Subject: [Bug gcov/profile/20815] -fprofile-use barfs with "coverage mismatch for function '...' while reading counter 'arcs'."
+
+
+------- Additional Comments From hubicka at ucw dot cz  2005-05-18 22:47 -------
+Subject: Re: [Bug gcov/profile/20815] -fprofile-use barfs with "coverage mismatch for function '...' while reading counter 'arcs'."
+
+> 
+> ------- Additional Comments From hubicka at ucw dot cz  2005-05-18 22:22 -------
+> Subject: Re: [Bug gcov/profile/20815] -fprofile-use barfs with "coverage mismatch for function '...' while reading counter 'arcs'."
+> 
+> coverage_checksum_string already knows a bit about ignoring random seed
+> produced mess.  It looks like this needs to be extended somehow to
+> handle namespaces too...
+
+This seems to solve the missmatch.  Would it be possible to test it on
+bigger testcase and if it works distile a testcase that don't use
+file IO so it is more suitable for gcc regtesting?
+
+Index: coverage.c
+===================================================================
+RCS file: /cvs/gcc/gcc/gcc/coverage.c,v
+retrieving revision 1.6.2.12.2.12
+diff -c -3 -p -r1.6.2.12.2.12 coverage.c
+*** gcc-old/gcc/coverage.c	18 May 2005 07:37:31 -0000	1.6.2.12.2.12
+--- gcc/gcc/coverage.c	18 May 2005 22:45:36 -0000
+*************** coverage_checksum_string (unsigned chksu
+*** 471,505 ****
+       as the checksums are used only for sanity checking.  */
+    for (i = 0; string[i]; i++)
+      {
+        if (!strncmp (string + i, "_GLOBAL__", 9))
+! 	for (i = i + 9; string[i]; i++)
+! 	  if (string[i]=='_')
+! 	    {
+! 	      int y;
+! 	      unsigned seed;
+! 	      int scan;
+! 
+! 	      for (y = 1; y < 9; y++)
+! 		if (!(string[i + y] >= '0' && string[i + y] <= '9')
+! 		    && !(string[i + y] >= 'A' && string[i + y] <= 'F'))
+! 		  break;
+! 	      if (y != 9 || string[i + 9] != '_')
+! 		continue;
+! 	      for (y = 10; y < 18; y++)
+! 		if (!(string[i + y] >= '0' && string[i + y] <= '9')
+! 		    && !(string[i + y] >= 'A' && string[i + y] <= 'F'))
+! 		  break;
+! 	      if (y != 18)
+! 		continue;
+! 	      scan = sscanf (string + i + 10, "%X", &seed);
+! 	      gcc_assert (scan);
+! 	      if (seed != crc32_string (0, flag_random_seed))
+! 		continue;
+! 	      string = dup = xstrdup (string);
+! 	      for (y = 10; y < 18; y++)
+! 		dup[i + y] = '0';
+! 	      break;
+! 	    }
+        break;
+      }
+  
+--- 471,511 ----
+       as the checksums are used only for sanity checking.  */
+    for (i = 0; string[i]; i++)
+      {
++       int offset = 0;
++       if (!strncmp (string + i, "_GLOBAL__N_", 11))
++ 	offset = 11;
+        if (!strncmp (string + i, "_GLOBAL__", 9))
+! 	offset = 9;
+! 
+!       /* C++ namespaces do have scheme:
+!          _GLOBAL__N_<filename>_<wrongmagicnumber>_<magicnumber>functionname
+! 	 since filename might contain extra underscores there seems
+! 	 to be no better chance then walk all possible offsets looking
+! 	 for magicnuber.  */
+!       if (offset)
+!         for (;string[offset]; offset++)
+! 	  for (i = i + offset; string[i]; i++)
+! 	    if (string[i]=='_')
+! 	      {
+! 		int y;
+! 
+! 		for (y = 1; y < 9; y++)
+! 		  if (!(string[i + y] >= '0' && string[i + y] <= '9')
+! 		      && !(string[i + y] >= 'A' && string[i + y] <= 'F'))
+! 		    break;
+! 		if (y != 9 || string[i + 9] != '_')
+! 		  continue;
+! 		for (y = 10; y < 18; y++)
+! 		  if (!(string[i + y] >= '0' && string[i + y] <= '9')
+! 		      && !(string[i + y] >= 'A' && string[i + y] <= 'F'))
+! 		    break;
+! 		if (y != 18)
+! 		  continue;
+! 		if (!dup)
+! 		  string = dup = xstrdup (string);
+! 		for (y = 10; y < 18; y++)
+! 		  dup[i + y] = '0';
+! 	      }
+        break;
+      }
+  
+
+
+-- 
+
+
+http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20815
+
+------- You are receiving this mail because: -------
+You reported the bug, or are watching the reporter.
+
+
diff --git a/patches/gcc/4.0.1/pr21951-fix2.patch b/patches/gcc/4.0.1/pr21951-fix2.patch
new file mode 100644
index 0000000..5e35a1e
--- /dev/null
+++ b/patches/gcc/4.0.1/pr21951-fix2.patch
@@ -0,0 +1,71 @@
+Workaround for buglet in std::vector etc. when compiling
+with gcc-4.0.1 -Wall -O -fno-exceptions
+Fixes:
+
+.../include/c++/4.0.0/bits/vector.tcc: In member function 'void std::vector<_Tp,
+_Alloc>::reserve(size_t) [with _Tp = int, _Alloc = std::allocator<int>]':
+.../include/c++/4.0.0/bits/vector.tcc:78: warning: control may reach end of
+non-void function 'typename _Alloc::pointer std::vector<_Tp,
+_Alloc>::_M_allocate_and_copy(size_t, _ForwardIterator, _ForwardIterator) [with
+_ForwardIterator = int*, _Tp = int, _Alloc = std::allocator<int>]' being inlined
+
+See http://gcc.gnu.org/PR21951
+
+To: gcc-patches at gcc dot gnu dot org
+Subject: [4.0.x] may reach end warning in system headers
+Message-Id: <20050701183024.E138714C16A9@geoffk5.apple.com>
+Date: Fri,  1 Jul 2005 11:30:24 -0700 (PDT)
+From: gkeating at apple dot com (Geoffrey Keating)
+
+
+One of our users was getting
+
+/usr/include/gcc/darwin/4.0/c++/bits/stl_uninitialized.h:113: warning:
+control may reach end of non-void function '_ForwardIterator
+std::__uninitialized_copy_aux(_InputIterator, _InputIterator,
+_ForwardIterator, __false_type) [with _InputIterator =
+__gnu_cxx::__normal_iterator<TPoolAllocator::tAllocState*,
+std::vector<TPoolAllocator::tAllocState,
+std::allocator<TPoolAllocator::tAllocState> > >, _ForwardIterator =
+__gnu_cxx::__normal_iterator<TPoolAllocator::tAllocState*,
+std::vector<TPoolAllocator::tAllocState,
+std::allocator<TPoolAllocator::tAllocState> > >]' being inlined
+
+which shouldn't be happening, he has no way to change a standard C++
+header.  The warning is bogus anyway, but it's fixed in 4.1 through
+the CFG changes, which I don't really want to backport to the 4.0
+branch, so instead I'll add this patch.  Other warnings generated from
+tree-inline.c check for DECL_SYSTEM_HEADER like this.
+
+Bootstrapped & tested on powerpc-darwin8, I'll commit when the branch
+is unfrozen.
+
+-- 
+- Geoffrey Keating <geoffk@apple.com>
+
+===File ~/patches/gcc-40-4121982.patch======================
+Index: ChangeLog
+2005-06-28  Geoffrey Keating  <geoffk@apple.com>
+
+	* tree-inline.c (expand_call_inline): Prevent 'may reach end'
+	warning in system headers.
+
+Index: tree-inline.c
+===================================================================
+RCS file: /cvs/gcc/gcc/gcc/tree-inline.c,v
+retrieving revision 1.170.8.4
+diff -u -p -u -p -r1.170.8.4 tree-inline.c
+--- gcc-4.0.1/gcc/tree-inline.c.old	6 Jun 2005 19:20:32 -0000	1.170.8.4
++++ gcc-4.0.1/gcc/tree-inline.c	1 Jul 2005 18:27:26 -0000
+@@ -1693,7 +1693,8 @@ expand_call_inline (tree *tp, int *walk_
+ 	&& !TREE_NO_WARNING (fn)
+ 	&& !VOID_TYPE_P (TREE_TYPE (TREE_TYPE (fn)))
+ 	&& return_slot_addr == NULL_TREE
+-	&& block_may_fallthru (copy))
++	&& block_may_fallthru (copy)
++	&& !DECL_IN_SYSTEM_HEADER (fn))
+       {
+ 	warning ("control may reach end of non-void function %qD being inlined",
+ 		 fn);
+============================================================
+