foibles upgrading from gcc3.0.2 to gcc3.0.4

[Dan Kegel]

Stop me if you've heard this one before:

We are upgrading from gcc3.0.2 to gcc3.0.4 to get around an ICE
in sh4 when building the sh4 linux kernel on x86.

First thing we noticed was that it wouldn't build unless we did
something like

--- gcc-3.0.4/configure.in      2001-08-13 09:14:49.000000000 -0700
+++ gcc-3.0.4/configure.in.new  2003-04-15 17:10:32.000000000 -0700
@@ -1442,7 +1442,7 @@
  # being built; programs in there won't even run.
  if test "${build}" = "${host}" && test -d ${topsrcdir}/gcc; then
    # Search for pre-installed headers if nothing else fits.
-  FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$(build_tooldir)/bin/ -B$(build_tooldir)/lib/ -isystem $(build_tooldir)/include'
+  FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$(build_tooldir)/bin/ -B$(build_tooldir)/lib/ -isystem $(build_tooldir)/include -isystem $(build_tooldir)/sys-include'
  fi

  if test "x${use_gnu_ld}" = x && test "x${with_gnu_ld}" != xno &&

though we're not sure that's right.

Second thing we noticed was that on sh4, one of the optimizations
caused trouble now on sh4 when it didn't before, so we brutally
disabled it with

--- gcc-3.0.4/gcc/toplev.c      2001-10-28 12:11:11.000000000 -0800
+++ gcc-3.0.4-new/gcc/toplev.c  2003-04-30 11:38:37.000000000 -0700
@@ -4744,7 +4744,12 @@
        flag_defer_pop = 1;
        flag_thread_jumps = 1;
  #ifdef DELAY_SLOTS
-      flag_delayed_branch = 1;
+/* Delay slot optimization is causing problems with the 3.0.4 gcc for sh.
+ * Do not, by default, include it in the list of optimizations done.
+ * It only gets added if the -fdelayed-branch option is used explicitly
+ */
+/*      flag_delayed_branch = 1; */
+      flag_delayed_branch = 0;
  #endif
  #ifdef CAN_DEBUG_WITHOUT_FP
        flag_omit_frame_pointer = 1;

Third thing I just noticed is that the resulting toolchain differs
in the installed limits.h in an annoying way:

$ diff /old/sh4_le/lib/gcc-lib/sh4-linux/3.0.2/include/limits.h /new/sh4_le/lib/gcc-lib/sh4-linux/3.0.4/include/limits.h
1,12d0
< /* This administrivia gets added to the beginning of limits.h
<    if the system has its own version of limits.h.  */
<
< /* We use _GCC_LIMITS_H_ because we want this not to match
<    any macros that the system's limits.h uses for its own purposes.  */
< #ifndef _GCC_LIMITS_H_  /* Terminated in limity.h.  */
< #define _GCC_LIMITS_H_
<
< #ifndef _LIBC_LIMITS_H_
< /* Use "..." so that we find syslimits.h only in this same directory.  */
< #include "syslimits.h"
< #endif
119,128d106
< /* This administrivia gets added to the end of limits.h
<    if the system has its own version of limits.h.  */
<
< #else /* not _GCC_LIMITS_H_ */
<
< #ifdef _GCC_NEXT_LIMITS_H
< #include_next <limits.h>              /* recurse down to the real one */
< #endif
<
< #endif /* not _GCC_LIMITS_H_ */

So perhaps that first change, passing -isystem to configure, wasn't such a hot idea?

I'm running a build again without that change to see what the error was.

- Dan



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com