[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed

["eraman at google dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #22 from Easwaran Raman <eraman at google dot com> ---
(In reply to Marek Polacek from comment #20)
> 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...

The problem with this test case is that there is a statement with uid 0 that is
being compared. The assumption was every stmt will have a UID in a
monotonically non-decreasing order. This is broken here because
force_gimple_operand_gsi generates new stmts that don't have a UID. The
proposed patch generates UIDs for these newly generated statements but I think
this is a bit ugly and fragile now.