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);

Reply via email to