This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix VRP ICE with -Wtype-limits (PR tree-optimization/64563)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]