On December 15, 2017 5:27:14 PM GMT+01:00, Jeff Law <l...@redhat.com> wrote: >On 12/15/2017 01:10 AM, Richard Biener wrote: >> On Thu, 14 Dec 2017, Richard Biener wrote: >> >>> On December 14, 2017 4:43:42 PM GMT+01:00, Jeff Law <l...@redhat.com> >wrote: >>>> On 12/14/2017 01:54 AM, Richard Biener wrote: >>>>> >>>>> IVOPTs (at least) leaves unfolded stmts in the IL and VRP >>>> overzealously >>>>> asserts they cannot happen. >>>>> >>>>> Bootstrap and regtest running on x86_64-unknown-linux-gnu. >>>>> >>>>> Richard. >>>>> >>>>> 2017-12-14 Richard Biener <rguent...@suse.de> >>>>> >>>>> PR tree-optimization/83418 >>>>> * vr-values.c >>>> (vr_values::extract_range_for_var_from_comparison_expr): >>>>> Instead of asserting we don't get unfolded comparisons deal with >>>>> them. >>>>> >>>>> * gcc.dg/torture/pr83418.c: New testcase. >>>> I think this also potentially affects dumping. I've seen the >dumper >>>> crash trying to access a INTEGER_CST where we expected to find an >>>> SSA_NAME while iterating over a statement's operands. >>>> >>>> I haven't submitted the workaround because I hadn't tracked down >the >>>> root cause to verify something deeper isn't wrong. >>> >>> Yes, I've seen this as well, see my comment in the PR. The issue is >that DOM calls VRP analyze (and dump) routines with not up to date >operands during optimize_stmt. >> >> I had the following in my tree to allow dumping. >> >> Richard. >> >> Index: gcc/tree-ssa-dom.c >> =================================================================== >> --- gcc/tree-ssa-dom.c (revision 255640) >> +++ gcc/tree-ssa-dom.c (working copy) >> @@ -2017,6 +2017,7 @@ dom_opt_dom_walker::optimize_stmt (basic >> undefined behavior that get diagnosed if they're >left in >> the >> IL because we've attached range information to new >> SSA_NAMES. */ >> + update_stmt_if_modified (stmt); >> edge taken_edge = NULL; >> evrp_range_analyzer.vrp_visit_cond_stmt (as_a <gcond *> > >> (stmt), >> &taken_edge); >> >I think this implies something earlier changed a statement without >updating it.
Dom itself does this and delays updating on purpose as an optimization. That doesn't work quite well when dispatching into different code. Richard. >jeff
