This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]