[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

2016-10-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

2016-10-11 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898 --- Comment #9 from Marc Glisse --- (In reply to Martin Sebor from comment #8) > I agree that in many cases there isn't enough information to tell that a > range is final and can't be further improved. But there certainly are such > cases (the t

[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

2016-10-10 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898 --- Comment #8 from Martin Sebor --- No, I get the range for _2 with a "def_stmt _2 = (sizetype) i_4;" i.0_1: [0, +INF] _2: ~[2147483648, 18446744071562067967] _3: [0, +INF] i_4: VARYING i_6(D): VARYING ... # i_4 = PHI _2 = (sizetype) i_4;

[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

2016-10-10 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898 --- Comment #7 from Marc Glisse --- (In reply to Martin Sebor from comment #6) > I meant a subrange of the i variable (i.e., a subrange of int). The range > of every variable is necessarily bounded by its type so returning a range of > [INT_MIN,

[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

2016-10-10 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898 --- Comment #6 from Martin Sebor --- I meant a subrange of the i variable (i.e., a subrange of int). The range of every variable is necessarily bounded by its type so returning a range of [INT_MIN, INT_MAX] for an int isn't terribly helpful. It

[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

2016-10-10 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898 --- Comment #5 from Marc Glisse --- (In reply to Martin Sebor from comment #4) > I suppose I was expecting that that after EVRP (and before VRP1) > get_range_info() would either succeed and return a range representing a > subrange of the the vari

[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

2016-10-10 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898 --- Comment #4 from Martin Sebor --- I suppose I was expecting that that after EVRP (and before VRP1) get_range_info() would either succeed and return a range representing a subrange of the the variable's type or fail and return VR_VARYING. If t

[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

2016-10-10 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898 --- Comment #3 from Marc Glisse --- (In reply to Martin Sebor from comment #2) > I may also be confused about other things but below is what I see in GDB > when I call get_range_info() from plus_stmt_object_size() on the offset in > POINTER_PLUS_

[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

2016-10-10 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898 Martin Sebor changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID