On Mon, Jan 12, 2015 at 01:37:47PM -0700, Jeff Law wrote:
> On 01/12/15 13:01, Jakub Jelinek wrote:
> >On the following testcase we ICE with -Os -Wtype-limits, as
> >VR_UNDEFINED has NULL vr0->min and vr0->max. From what the code
> >does I believe the code only means to handle VR_RANGE and not anything else.
> >
> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> >2015-01-12 Jakub Jelinek <ja...@redhat.com>
> >
> > PR tree-optimization/64563
> > * tree-vrp.c (vrp_evaluate_conditional): Check for VR_RANGE
> > instead of != VR_VARYING.
> >
> > * gcc.dg/pr64563.c: New test.
> What about VR_ANTI_RANGE here? I'm pretty sure vrp_evaluate_conditional's
> children will use anti-ranges to simplify conditionals to constants. Though
> I guess that doesn't really matter when it comes to this warning because of
> the minmax testing... Nevermind.
It checks for the case where e.g. enum has a smaller range of values than
the underlying integer type, and tests min and max of the range against
the enum type's min/max. For VR_ANTI_RANGE, that would have to be
~[type_min, type_max], i.e. say that the value is always not in the right
range (thus always undefined behavior), so something we don't have to bother
with. And, to handle VR_ANTI_RANGE, the diagnostics would need to change.
Jakub
