On Mon, 27 Apr 2015, Jakub Jelinek wrote:
> On Mon, Apr 27, 2015 at 10:05:21AM +0200, Richard Biener wrote:
> > > --- gcc/tree-vrp.c.jj 2015-04-20 14:35:39.000000000 +0200
> > > +++ gcc/tree-vrp.c 2015-04-24 18:10:41.321367440 +0200
> > > @@ -892,7 +892,12 @@ update_value_range (const_tree var, valu
> > > UNDEFINED or from VARYING. */
> > > if (new_vr->type == VR_UNDEFINED
> > > || old_vr->type == VR_VARYING)
> > > - set_value_range_to_varying (old_vr);
> > > + {
> > > + BITMAP_FREE (new_vr->equiv);
> > > + set_value_range_to_varying (old_vr);
> > > + set_value_range_to_varying (new_vr);
> > > + return true;
> >
> > Actually we didn't change anything here (old_vr->type is VARYING already,
> > so we shouldn't even have visited the stmt defining the SSA name again...
> > eventually your fix below fixes that.
>
> On the testcase, old_vr wasn't actually VARYING, but new_vr was UNDEFINED
> (a result of intersecting disjoint ranges). While for old_vr->type ==
> VR_VARYING I agree we shouldn't have been called on this.
>
> And turning a VR_RANGE into VR_UNDEFINED is going in the wrong direction
> in the lattice.
Ah, I misread the || for a &&. The patch is ok with just dropping
the == VR_VARYING check.
Thanks,
Richard.
