diff options
Diffstat (limited to 'patches/gcc/4.0.1')
-rw-r--r-- | patches/gcc/4.0.1/fix-fixincl.patch | 72 | ||||
-rw-r--r-- | patches/gcc/4.0.1/pr20815-fix.patch | 121 | ||||
-rw-r--r-- | patches/gcc/4.0.1/pr21951-fix2.patch | 71 |
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); +============================================================ + |