This is the 2nd thing I came up with after looking at PR64277.
VRP does a poor job computing value-ranges of unrolled loop IVs
thus a very simple thing to do is to factor in previous VRP results
by intersecting what VRP2 computes with recorded SSA name range infos
(that also makes errors in those more likely to pop up... :/).
This reduces the number of array bound warnings I get from the testcase
but doesn't fix it completely. It also ends up with saner value-ranges.
Bootstrapped and tested on x86_64-unknown-linux-gnu (with one
libstdc++ runtime failure which I am now checking if caused by the patch,
and thus likely an existing latent issue with SSA name range info).
Ok for trunk? Or should I delay this to GCC 6?
Thanks,
Richard.
2015-01-26 Richard Biener <rguent...@suse.de>
PR tree-optimization/64277
* tree-vrp.c (update_value_range): Intersect the range with
old recorded SSA name range information.
Index: gcc/tree-vrp.c
===================================================================
--- gcc/tree-vrp.c (revision 220107)
+++ gcc/tree-vrp.c (working copy)
@@ -847,6 +847,23 @@ update_value_range (const_tree var, valu
value_range_t *old_vr;
bool is_new;
+ /* If there is a value-range on the SSA name from earlier analysis
+ factor that in. */
+ if (INTEGRAL_TYPE_P (TREE_TYPE (var)))
+ {
+ wide_int min, max;
+ value_range_type rtype = get_range_info (var, &min, &max);
+ if (rtype == VR_RANGE || rtype == VR_ANTI_RANGE)
+ {
+ value_range_d nr;
+ nr.type = rtype;
+ nr.min = wide_int_to_tree (TREE_TYPE (var), min);
+ nr.max = wide_int_to_tree (TREE_TYPE (var), max);
+ nr.equiv = NULL;
+ vrp_intersect_ranges (new_vr, &nr);
+ }
+ }
+
/* Update the value range, if necessary. */
old_vr = get_value_range (var);
is_new = old_vr->type != new_vr->type
