Bug 44901

Summary: [4.6 Regression] -fcompare-debug failure for tree-predcom.c
Product: gcc Reporter: Jorn Wolfgang Rennecke <amylaar>
Component: debugAssignee: Jakub Jelinek <jakub>
Severity: normal CC: froydnj, gcc-bugs
Priority: P3 Keywords: build
Version: 4.6.0   
Target Milestone: 4.6.0   
Host: i686-pc-linux-gnu Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2010-07-10 15:37:50
Attachments: test case - compressed with xz

Description Jorn Wolfgang Rennecke 2010-07-10 10:48:54 UTC
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).
Comment 1 Jorn Wolfgang Rennecke 2010-07-10 10:53:44 UTC
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
Comment 2 H.J. Lu 2010-07-10 15:37:50 UTC
It is caused by revision 161862:

Comment 3 Jakub Jelinek 2010-07-12 10:19:09 UTC
Fails even with -fno-var-tracking, so does not look VTA related.
Comment 4 Jakub Jelinek 2010-07-12 14:26:08 UTC
Created attachment 21183 [details]

Reduced testcase:

./xgcc -B ./ -S -m32 -fcompare-debug -O2 -fno-var-tracking /tmp/pr44901.i -w
xgcc: error: /tmp/pr44901.i: -fcompare-debug failure
Comment 5 Jakub Jelinek 2010-07-12 14:50:20 UTC
All the unordered removals for local_decls are obviously wrong.
Comment 6 froydnj@codesourcery.com 2010-07-12 14:56:53 UTC
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
bootstrap config?
Comment 7 Jakub Jelinek 2010-07-12 15:23:58 UTC
Created attachment 21185 [details]

Untested fix.

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.
Comment 8 Jakub Jelinek 2010-07-13 07:00:12 UTC
Subject: Bug 44901

Author: jakub
Date: Tue Jul 13 06:59:56 2010
New Revision: 162126

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162126
	PR debug/44901
	* 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.


Comment 9 Jakub Jelinek 2010-07-13 11:40:06 UTC