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

--- Comment #20 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Yes, the patch maybe fixes the debuginfo issue, but there's something else that
is wrong.  E.g., on the testcase from PR58018, we have in reassociate_bb
*after*
(and that is important) optimize_range_tests this:

<bb 7>:
[...]
e.1_16 = _14 & e.0_15;
_17 = f_12 >= 0;
_18 = (int) _17;
e.1_19 = e.1_16 & _18;
_20 = f_12 > 0;
_23 = f_12 > 0;
_24 = (int) _23;
_21 = (int) _20;
e.1_22 = e.1_19 & _21;
[...]

Now, in reassociate_bb, we go over the stmts, from the last stmt to the first
stmt in the bb.  For the appropriate stmts, we call rewrite_expr_tree to
rewrite the linearized statements according to the operand_entry_t ops vector,
in this case we call it on
  e.1_22 = e.1_19 & _21;
and the vector ops contains
  Op 0 -> rank: 589826, tree: _14
  Op 1 -> rank: 3, tree: _24
  Op 2 -> rank: 1, tree: e.0_15

In rewrite_expr_tree, we recursively call this function on e.1_19, whose
SSA_NAME_DEF_STMT is
  e.1_19 = e.1_16 & _18;
This stmt is then transformed into
  e.1_19 = _24 & e.0_15;

But, at the point where e.1_19 is defined, the _24 isn't defined yet!

So, it seems, ensure_ops_are_available should handle a situation like this. 
However, it doesn't: perhaps the issue is that find_insert_point won't find the
right insert point (the stmt is e.1_19 = e.1_16 & _18;, the dep_stmt is _24 =
(int) _23;), in there we have:

  if (gimple_uid (insert_stmt) == gimple_uid (dep_stmt)
      && gimple_bb (insert_stmt) == gimple_bb (dep_stmt)
      && insert_stmt != dep_stmt)
    insert_stmt = appears_later_in_bb (insert_stmt, dep_stmt);
  else if (not_dominated_by (insert_stmt, dep_stmt))
    insert_stmt = dep_stmt;
  return insert_stmt;

Neither of these condition holds; gimple_uid of the dep_stmt is 0 and of
insert_stmt it is 16.  Thus, find_insert_point returns e.1_19 = e.1_16 & _18;. 
That's wrong, I suppose.
Maybe the issue is that if the two stms are in the same bb, we just look at
their UIDs and based on that we find out the dependency, but the new stms
coming  from optimize_range_tests don't have gimple UIDs set, thus this can't
work.
Likely I'm wrong, would appreciate if someone could shed some light on this.

Looking into it more...

Reply via email to