* [Bug middle-end/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245
2014-03-01 21:25 [Bug middle-end/60381] New: [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245 danglin at gcc dot gnu.org
@ 2014-03-01 21:38 ` danglin at gcc dot gnu.org
2014-03-03 8:59 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: danglin at gcc dot gnu.org @ 2014-03-01 21:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381
--- Comment #1 from John David Anglin <danglin at gcc dot gnu.org> ---
(gdb) r
Starting program: /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgcc/../../gcc/cc1
-fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -auxbase-strip _divdc3.o -g
-g -g -O2 -O2 -O2 -Wextra -Wall -Wwrite-strings -Wcast-qual -Wformat=0
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version
-fbuilding-libgcc -fno-stack-protector -fPIC -fvisibility=hidden -o libgcc2.s
GNU C (GCC) version 4.9.0 20140228 (experimental) [trunk revision 208220]
(hppa-linux-gnu)
compiled by GNU C version 4.6.4, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.9.0 20140228 (experimental) [trunk revision 208220]
(hppa-linux-gnu)
compiled by GNU C version 4.6.4, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: e5ddc5eadc758a9e6fcf473bee448b45
Breakpoint 1, vt_expand_var_loc_chain (var=0x14df4d0, regs=0x14817ac,
data=0xfaf02d4c, pendrecp=0xfaf03610) at ../../gcc/gcc/var-tracking.c:8245
8245 gcc_checking_assert (cselib_preserved_value_p (val));
(gdb) p val
$1 = (cselib_val *) 0x14bce80
(gdb) p *val
$2 = {hash = 7, uid = 7, val_rtx = 0x14ddda0, locs = 0x0, addr_list = 0x0,
next_containing_mem = 0x0}
(gdb) p debug_rtx (val->val_rtx)
(value/f/i:SI 7:7 @0x14ddda0/0x14bce80)
$3 = void
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug middle-end/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245
2014-03-01 21:25 [Bug middle-end/60381] New: [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245 danglin at gcc dot gnu.org
2014-03-01 21:38 ` [Bug middle-end/60381] " danglin at gcc dot gnu.org
@ 2014-03-03 8:59 ` rguenth at gcc dot gnu.org
2014-03-03 15:02 ` mpolacek at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-03-03 8:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
Target Milestone|--- |4.9.0
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug middle-end/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245
2014-03-01 21:25 [Bug middle-end/60381] New: [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245 danglin at gcc dot gnu.org
2014-03-01 21:38 ` [Bug middle-end/60381] " danglin at gcc dot gnu.org
2014-03-03 8:59 ` rguenth at gcc dot gnu.org
@ 2014-03-03 15:02 ` mpolacek at gcc dot gnu.org
2014-03-03 15:53 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2014-03-03 15:02 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P1 |P2
CC| |mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Seems like hppa only, thus does not merit P1.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug middle-end/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245
2014-03-01 21:25 [Bug middle-end/60381] New: [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245 danglin at gcc dot gnu.org
` (2 preceding siblings ...)
2014-03-03 15:02 ` mpolacek at gcc dot gnu.org
@ 2014-03-03 15:53 ` jakub at gcc dot gnu.org
2014-03-05 8:55 ` [Bug debug/60381] " jakub at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-03-03 15:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This seems to be due to r208220.
One problem I see is that when var-tracking.c calls cselib_preserve_only_values
+ cselib_reset_table, the latter clears n_useless_values (and
n_useless_debug_values) and drops non-preserved VALUEs with no locations, so
while we get rid of the non-preserved VALUEs with no locations, it can happen
that discard_useless_locs is never performed, even when the cumulative number
of dropped useless locs became very large.
So, I wonder if r208220 shouldn't be reverted and instead we'd use slightly
different condition on when to call remove_useless_values from
cselib_preserve_only_values, or perhaps just do the
do
{
values_became_useless = 0;
cselib_hash_table.traverse <void *, discard_useless_locs> (NULL);
}
while (values_became_useless);
part of remove_useless_values, since the rest of the function does nothing or
is useless with the immediately following cselib_reset_table (is it?) or
cselib_invalidate_mem (callmem) done right before that. For the different
condition, I'd imagine that for cselib_preserve_constants we'd sum up in some
new int variable the n_useless_values counts from entry to cselib_reset_table,
and clear that inside of remove_useless_locs and use that in the guard
condition when to discard useless locs from cselib_preserve_only_values. Thus,
if we say have 30000 ebbs and in each of them gain say 10 useless values (that
are dropped), we'd eventually discard_useless_locs at least after some ebbs,
though not after each one.
Also, I wonder because of this ICE if we shouldn't forcefully
remove_useless_values (if any values have become useless since last
discard_useless_locs call) at the end of vt_initialize, to make sure we don't
have useless locs at the end, and also
cselib_preserved_hash_table.traverse <void *, discard_useless_locs> (NULL);
after that (so that we don't reference non-preserved VALUEs from preserved
VALUE locs). We don't need to retry that, because cselib_preserved_hash_table
contains only preserved values and thus value_became_useless should be always
unchanged while walking that table.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245
2014-03-01 21:25 [Bug middle-end/60381] New: [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245 danglin at gcc dot gnu.org
` (3 preceding siblings ...)
2014-03-03 15:53 ` jakub at gcc dot gnu.org
@ 2014-03-05 8:55 ` jakub at gcc dot gnu.org
2014-03-05 16:00 ` aoliva at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-03-05 8:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note I've posted a patch in the mean time:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00142.html
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245
2014-03-01 21:25 [Bug middle-end/60381] New: [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245 danglin at gcc dot gnu.org
` (4 preceding siblings ...)
2014-03-05 8:55 ` [Bug debug/60381] " jakub at gcc dot gnu.org
@ 2014-03-05 16:00 ` aoliva at gcc dot gnu.org
2014-03-05 19:01 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: aoliva at gcc dot gnu.org @ 2014-03-05 16:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381
--- Comment #6 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Created attachment 32274
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32274&action=edit
WIP patch to start combining useless value removal and table reset, after
reverting the faulty patch
I'd prefer if we kept the preserved table without potentially useless locs.
I've struggled for several hours this morning trying to combine useless value
removal, preservation of values in the alternate table, detection of constants
and equivalences for preservation and discarding values that should not be
preserved into fewer passes over the hash table, unfortunately without much
success. In the end, I returned to mostly separate removal and reset passes,
but I've managed to make both passes optional, except at the end of
vt_initialize. Here's the WIP patch, to be applied after the reversal of the
faulty patch. Unfortunately, the result is not much faster than the reversal,
probably because it works much harder to release cselib_vals and loc lists as
they get removed from the table, instead of just dropping them on the floor
till the pool is released as a whole.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245
2014-03-01 21:25 [Bug middle-end/60381] New: [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245 danglin at gcc dot gnu.org
` (5 preceding siblings ...)
2014-03-05 16:00 ` aoliva at gcc dot gnu.org
@ 2014-03-05 19:01 ` jakub at gcc dot gnu.org
2014-03-06 7:05 ` aoliva at gcc dot gnu.org
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-03-05 19:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've measured (everything --enable-checking=release bootstrapped) vanilla
trunk, that + my http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00142.html patch,
trunk with 208220 reverted and the same plus your WIP patch on insn-recog.ii
(on a SNB box):
vanilla
real 2m11.855s
user 2m9.917s
sys 0m1.479s
my
real 2m11.760s
user 2m9.823s
sys 0m1.449s
208220revert
real 2m11.632s
user 2m9.847s
sys 0m1.310s
lxo
real 2m12.491s
user 2m10.699s
sys 0m1.304s
so I guess all the changes are pretty much in the noise when the r208221 change
is in, so we might as well just revert r208220 and do nothing else.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245
2014-03-01 21:25 [Bug middle-end/60381] New: [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245 danglin at gcc dot gnu.org
` (6 preceding siblings ...)
2014-03-05 19:01 ` jakub at gcc dot gnu.org
@ 2014-03-06 7:05 ` aoliva at gcc dot gnu.org
2014-03-06 8:17 ` aoliva at gcc dot gnu.org
2014-03-06 8:19 ` aoliva at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: aoliva at gcc dot gnu.org @ 2014-03-06 7:05 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381
--- Comment #9 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Author: aoliva
Date: Thu Mar 6 07:04:47 2014
New Revision: 208361
URL: http://gcc.gnu.org/viewcvs?rev=208361&root=gcc&view=rev
Log:
PR debug/60381
Revert:
2014-02-28 Alexandre Oliva <aoliva@redhat.com>
PR debug/59992
* cselib.c (remove_useless_values): Skip to avoid quadratic
behavior if the condition moved from...
(cselib_process_insn): ... here holds.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cselib.c
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245
2014-03-01 21:25 [Bug middle-end/60381] New: [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245 danglin at gcc dot gnu.org
` (7 preceding siblings ...)
2014-03-06 7:05 ` aoliva at gcc dot gnu.org
@ 2014-03-06 8:17 ` aoliva at gcc dot gnu.org
2014-03-06 8:19 ` aoliva at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: aoliva at gcc dot gnu.org @ 2014-03-06 8:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381
Alexandre Oliva <aoliva at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |UNCONFIRMED
Ever confirmed|1 |0
--- Comment #10 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Fixed by reversal of the faulty patch. We should eventually tweak
vt_add_function_parameter so as to preserve VALUEs recursively, adding
dataflow_set binds for all of them, like we do for top-level MEMs (and their
addresses) and REGs. We'll probably have to work harder to preserve these
intermediate equivalences in spite of the removal of the base VALUEs when their
REGs are reset and their loc lists become empty. Just marking the VALUEs as
preserved won't stop that, and when we get to preserving them in the separate
preserved table, they'll be gone already. Regarding preserved values as
non-useless will likely cause lots of values to be preserved that currently
aren't. This may very well get us better debug info, but I'm not sure at what
cost.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245
2014-03-01 21:25 [Bug middle-end/60381] New: [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245 danglin at gcc dot gnu.org
` (8 preceding siblings ...)
2014-03-06 8:17 ` aoliva at gcc dot gnu.org
@ 2014-03-06 8:19 ` aoliva at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: aoliva at gcc dot gnu.org @ 2014-03-06 8:19 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381
Alexandre Oliva <aoliva at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #11 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Oops, really fixed now ;-)
^ permalink raw reply [flat|nested] 11+ messages in thread