We currently have a bootstrap-lean failure on tree-predcom.c .
The preprocessed file shows a compare-debug failure for
gcc (GCC) 4.6.0 20100708 (experimental), but not for
gcc (GCC) 4.6.0 20100705 (experimental), gcc (GCC) 4.6.0 20100630 (experimental)
or gcc (GCC) 4.4.4 20100630 (Red Hat 4.4.4-10).
Created attachment 21174 [details]
test case - compressed with xz
$ ./bld-20100708/gcc/xgcc -B./bld-20100708/gcc -c -fpreprocessed -g -O2 -fomit-frame-pointer -fcompare-debug -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common treepred.c
xgcc: error: treepred.c: -fcompare-debug failure
It is caused by revision 161862:
Fails even with -fno-var-tracking, so does not look VTA related.
Created attachment 21183 [details]
./xgcc -B ./ -S -m32 -fcompare-debug -O2 -fno-var-tracking /tmp/pr44901.i -w
xgcc: error: /tmp/pr44901.i: -fcompare-debug failure
All the unordered removals for local_decls are obviously wrong.
Subject: Re: [4.6 Regression] -fcompare-debug failure for
Why are the unordered removals "obviously" wrong? And why, if they're
"obviously" wrong, does this problem only turn up with a specific
Created attachment 21185 [details]
Expansion depends on the order of vars in cfun->local_decls, see e.g.
expand_used_vars. The removal of vars from local_decls sometimes depends on whether compiling with -g or -g0, and the unordered removal changes the relative ordering between vars that are going to get pseudos/memory assigned, which means -g/-g0 affect (resp. might affect) code generation, which is undesirable.
Subject: Bug 44901
Date: Tue Jul 13 06:59:56 2010
New Revision: 162126
* vec.h (VEC_block_remove): Fix comment.
* tree-ssa-live.c (remove_unused_locals): Don't use
VEC_unordered_remove on local_decls, instead replace a single
vector element in each iteration if at least one element had
to be removed and VEC_truncate at the end.
* omp-low.c (expand_omp_taskreg): Likewise.