This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix VRP ICE with -Wtype-limits (PR tree-optimization/64563)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Richard Biener <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 12 Jan 2015 21:41:57 +0100
- Subject: Re: [PATCH] Fix VRP ICE with -Wtype-limits (PR tree-optimization/64563)
- Authentication-results: sourceware.org; auth=none
- References: <20150112200112 dot GO1405 at tucnak dot redhat dot com> <54B4309B dot 30609 at redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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 <jakub@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