------- Additional Comments From steven at gcc dot gnu dot org 2005-06-28
14:06 -------
It is maybe a bit hard to investigate this bug because it actually causes
bootstrap failures on e.g. ia64, and even a normal "make" seems to produce
bad crt* stuff. So I took a different approach:
Index: common.opt
===================================================================
RCS file: /cvs/gcc/gcc/gcc/common.opt,v
retrieving revision 1.77
diff -u -3 -p -r1.77 common.opt
--- common.opt 28 Jun 2005 02:20:28 -0000 1.77
+++ common.opt 28 Jun 2005 13:53:10 -0000
@@ -1014,6 +1014,10 @@ fzero-initialized-in-bss
Common Report Var(flag_zero_initialized_in_bss) Init(1)
Put zero initialized data in the bss section
+fzzzz
+Common Report Var(flag_zzzz) Init(0)
+Flag for testing some feature
+
g
Common JoinedOrMissing
Generate debug information in default format
Index: sched-deps.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/sched-deps.c,v
retrieving revision 1.93
diff -u -3 -p -r1.93 sched-deps.c
--- sched-deps.c 25 Jun 2005 02:01:03 -0000 1.93
+++ sched-deps.c 28 Jun 2005 13:53:10 -0000
@@ -149,7 +149,10 @@ sched_get_condition (rtx insn)
return 0;
src = SET_SRC (pc_set (insn));
-#if 0
+#if 1
+ if (!flag_zzzz)
+ return 0;
+
/* The previous code here was completely invalid and could never extract
the condition from a jump. This code does the correct thing, but that
triggers latent bugs later in the scheduler on ports with conditional
I used this patch and compared the gcc.dg execute.exp results of a normal test
run with the results of the patched compiler, i.e. the diff of the output of
make check-gcc RUNTESTFLAGS="execute.exp"
and
make check-gcc RUNTESTFLAGS="execute.exp --tool_opts '-fzzzz'"
which shows that on an Itanium2 box the following test cases work with the
code in sched_get_condition disabled, but fail with the patch:
0a1,5
> FAIL: gcc.c-torture/execute/20010209-1.c execution, -O2
> FAIL: gcc.c-torture/execute/20010209-1.c execution, -O3
-fomit-frame-pointer
> FAIL: gcc.c-torture/execute/20010209-1.c execution, -O3
-fomit-frame-pointer -funroll-loops
> FAIL: gcc.c-torture/execute/20010209-1.c execution, -O3
-fomit-frame-pointer -funroll-all-loops -finline-functions
> FAIL: gcc.c-torture/execute/20010209-1.c execution, -O3 -g
7a13,22
> FAIL: gcc.c-torture/execute/920625-1.c compilation, -O3
-fomit-frame-pointer -funroll-loops
> FAIL: gcc.c-torture/execute/920625-1.c compilation, -O3
-fomit-frame-pointer -funroll-all-loops -finline-functions
> FAIL: gcc.c-torture/execute/990127-1.c execution, -O2
> FAIL: gcc.c-torture/execute/990127-1.c execution, -O3 -fomit-frame-pointer
> FAIL: gcc.c-torture/execute/990127-1.c execution, -O3 -g
> FAIL: gcc.c-torture/execute/va-arg-10.c execution, -O2
> FAIL: gcc.c-torture/execute/va-arg-10.c execution, -O3 -fomit-frame-pointer
> FAIL: gcc.c-torture/execute/va-arg-10.c execution, -O3 -fomit-frame-pointer
-funroll-loops
> FAIL: gcc.c-torture/execute/va-arg-10.c execution, -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions
> FAIL: gcc.c-torture/execute/va-arg-10.c execution, -O3 -g
There. At least this should at last make it a bit easier to investigate this
nasty bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17808
