On December 21, 2017 5:40:48 AM GMT+01:00, Jeff Law <l...@redhat.com> wrote: >On 12/15/2017 09:30 AM, Richard Biener wrote: >> 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. >So I went ahead with a bootstrap and regression test with this patch. >If (of course) worked fine. I'm installing it on the trunk.
Thanks. Richard. >jeff
