OpenE2K/gcc
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

re PR ada/25900 (ICE on ACATS cxac004 in Tree-VRP)

Browse Source 
PR ada/25900
	* tree-vrp.c (extract_range_from_assert): When merging a VR_RANGE
	with a VR_ANTI_RANGE and the VR_ANTI_RANGEis completely contained
	within the VR_RANGE, use the VR_RANGE as the result, not the
	VR_ANTI_RANGE.
	(adjust_range_with_scev): Reject ranges from SCEV which are out
	of bounds for the type.

From-SVN: r110261
This commit is contained in:
Jeff Law 2006-01-26 10:14:22 -07:00
parent f4e18df2de
commit 4f67dfcf24
2 changed files with 28 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
gcc/ChangeLog
View File

@ -1,4 +1,14 @@
2006-01-26 Daniel Berlin <dberlin@dberlin.org> 2006-01-26 Jeff Law <law@redhat.com>
PR ada/25900
* tree-vrp.c (extract_range_from_assert): When merging a VR_RANGE
with a VR_ANTI_RANGE and the VR_ANTI_RANGEis completely contained
within the VR_RANGE, use the VR_RANGE as the result, not the
VR_ANTI_RANGE.
(adjust_range_with_scev): Reject ranges from SCEV which are out
of bounds for the type.
2005-01-26 Daniel Berlin <dberlin@dberlin.org>
* tree-ssa-alias.c (maybe_create_global_var): Change * tree-ssa-alias.c (maybe_create_global_var): Change
subvar walking to an assertion that we don't have subvar'd variables. subvar walking to an assertion that we don't have subvar'd variables.

24
gcc/tree-vrp.c
View File

@ -1059,7 +1059,8 @@ extract_range_from_assert (value_range_t *vr_p, tree expr)
1. The VR_ANTI_RANGE range is competely within the 1. The VR_ANTI_RANGE range is competely within the
VR_RANGE and the endpoints of the ranges are VR_RANGE and the endpoints of the ranges are
different. In that case the resulting range different. In that case the resulting range
should be the VR_ANTI_RANGE. should be whichever range is more precise.
Typically that will be the VR_RANGE.
2. The VR_ANTI_RANGE is completely disjoint from 2. The VR_ANTI_RANGE is completely disjoint from
the VR_RANGE. In this case the resulting range the VR_RANGE. In this case the resulting range
@ -1100,8 +1101,8 @@ extract_range_from_assert (value_range_t *vr_p, tree expr)
if (compare_values (anti_max, real_max) == -1 if (compare_values (anti_max, real_max) == -1
&& compare_values (anti_min, real_min) == 1) && compare_values (anti_min, real_min) == 1)
{ {
set_value_range (vr_p, VR_ANTI_RANGE, anti_min, set_value_range (vr_p, VR_RANGE, real_min,
anti_max, vr_p->equiv); real_max, vr_p->equiv);
} }
/* Case 2, VR_ANTI_RANGE completely disjoint from /* Case 2, VR_ANTI_RANGE completely disjoint from
VR_RANGE. */ VR_RANGE. */
@ -1918,12 +1919,21 @@ adjust_range_with_scev (value_range_t *vr, struct loop *loop, tree stmt,
{ {
/* For VARYING or UNDEFINED ranges, just about anything we get /* For VARYING or UNDEFINED ranges, just about anything we get
from scalar evolutions should be better. */ from scalar evolutions should be better. */
tree min = TYPE_MIN_VALUE (TREE_TYPE (init));
tree max = TYPE_MAX_VALUE (TREE_TYPE (init));
if (init_is_max) if (init_is_max)
set_value_range (vr, VR_RANGE, TYPE_MIN_VALUE (TREE_TYPE (init)), max = init;
init, vr->equiv);
else else
set_value_range (vr, VR_RANGE, init, TYPE_MAX_VALUE (TREE_TYPE (init)), min = init;
vr->equiv);
/* If we would create an invalid range, then just assume we
know absolutely nothing. This may be over-conservative,
but it's clearly safe. */
if (compare_values (min, max) == 1)
return;
set_value_range (vr, VR_RANGE, min, max, vr->equiv);
} }
else if (vr->type == VR_RANGE) else if (vr->type == VR_RANGE)
{ {