This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names
- From: "rguenth at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 13 Oct 2006 09:18:55 -0000
- Subject: [Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names
- References: <bug-29446-10110@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #4 from rguenth at gcc dot gnu dot org 2006-10-13 09:18 -------
We end up comparing (GT_EXPR) i_92 with ubound1_111 which have the following
value ranges and equivalences:
i_92: [1, 3] EQUIVALENCES: { i_1 j_2 i_67 j_70 } (4 elements)
i_1: ~[0, 0] EQUIVALENCES: { } (0 elements)
j_2: VARYING
i_67: [1, ubound1_8] EQUIVALENCES: { i_1 } (1 elements)
j_70: [-INF, 3] EQUIVALENCES: { j_2 } (1 elements)
ubound1_111: [-INF, 0] EQUIVALENCES: { ubound1_8 ubound1_112 } (2 elements)
ubound1_8: VARYING
ubound1_112: [i_67, +INF] EQUIVALENCES: { ubound1_8 } (1 elements)
i_67 > ubound1_8 ([1, ubound1_8] > [ubound1_8, ubound1_8]) is false
i_67 > ubound1_111 ([1, ubound1_8] > [-INF, 0]) is true
i_92 > ubound1_111 ([1, 3] > [-INF, 0]) is true
So we have a cross-equivalency set inconsistency.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29446