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/54327] [4.8 Regression] Segmentation fault in init_ggc


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-08-20 08:53:13 UTC ---
The issue is that we now merge two blocks we didn't merge before which
introduces SSA names into a STMT that are marked for update (thus, in
old_ssa_names):

  <bb 10>:
  # a_12 = PHI <0B(3)>
  _13 = *a_1;
  _14 = (int) _4;
  _15 = _4 == 0;
  _16 = (int) _6;
  goto <bb 7>;

  <bb 7>:
  # a_11 = PHI <a_1(10)>
  _9 = strlen (a_11);
  if (_9 <= 1)
    goto <bb 8>;
  else
    goto <bb 9>;

a_1 is marked to be replaced by a_12, block merging from CFG cleanup
(called via TODO, which calls CFG cleanup before updating SSA form ...)
now replaces a_11 with a_1 in _9 = strlen (a_11) via replace_uses_by
which ends up folding the stmt (but a_1 has a dead DEF stmt).

update_ssa only needs unreachable blocks removed to make DOM info
computable.  So this might be solved by re-ordering cfgcleanup/SSA update
in the TODO.  OTOH passes registering things for manual SSA update should
eventually call update_ssa themselves, not relying on TODO (in this case
it is jump threading from DOM).  OTOH calling into SSA def stmt walking
folders from this situation is bad, the folding in question is
gimple_fold_builtin calling get_maxval_strlen (which may even result in
wrong-code with a non-up-to-date SSA form).

So the bug IMHO is fold_stmt walking SSA def stmts.


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