[Bug middle-end/85598] [7/8/9 Regression] Incorrect warning only at -O2 and -O3

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85598

--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 23 Nov 2018, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85598
> 
> --- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> So, evrp_range_analyzer.enter (bb); even calls record_ranges_from_phis, but
> that does nothing here, as only one of the preds is BB_VISITED and the other is
> not when this is called, so we end up with has_unvisited_preds and so
> extract_range_from_phi_node isn't called.  Could we just drop the
> has_unvisited_preds stuff and instead in extract_range_from_phi_node for the
> edges from non-visited bbs solely use get_range_info?

We could do that, yes.

> Plus, we'd need for both the visited and unvisited add the range intersection
> with the guarding condition of the edge if it uses the same SSA_NAME (or
> perhaps later extend it to be as smart as tree-vrp.c assertion handling is, it
> handles even some more complex cases).  Or is it that in evrp code we never
> want to look at recorded SSA_NAME_RANGE_INFO?

EVRP already factors this in.  Thus record_ranges_from_incoming_edge is
assumed to adjust the range info in the (temporary) lattice.

> And lastly, even if all this is done, I believe dom just computes ranges, but
> doesn't every adjust (narrow) recorded SSA_NAME_RANGE_INFO if it computes
> something more precise for some SSA_NAME.  Can it do that?

The EVRP analysis code does so.  But yes, if DOM simplifies sth
the range code isn't re-done.  IIRC I once tried switching
the two calls in

  edge taken_edge = NULL;
  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
    {
      evrp_range_analyzer.record_ranges_from_stmt (gsi_stmt (gsi), false);
      taken_edge = this->optimize_stmt (bb, gsi);
    }

or I even did?