Building libgcc, I get:
/scratch/dan/mips-nonpic-upstream/src/gcc-mainline/libgcc/../gcc/unwind-pe.h:
In function 'size_of_encoded_value':
/scratch/dan/mips-nonpic-upstream/src/gcc-mainline/libgcc/../gcc/unwind-pe.h:78:
internal compiler error: tree check: accessed elt 7 of tree_vec with 5 elts in
find_switch_asserts, at tree-vrp.c:4346
/scratch/dan/mips-nonpic-upstream/src/gcc-mainline/libgcc/../gcc/unwind-dw2.c:1257:
internal compiler error: tree check: accessed elt 9 of tree_vec with 7 elts in
find_switch_asserts, at tree-vrp.c:4346
If I recompile tree-vrp.o with -O0, then libgcc compiles OK.
Joseph suggests this came in at the time of the tuples merge. If possible, it
would be nice if we could avoid the problematic construct...
The code in question is:
/* If there are multiple case labels with the same destination
we need to combine them to a single value range for the edge. */
if (idx + 1 < n
&& CASE_LABEL (cl) == CASE_LABEL (TREE_VEC_ELT (vec2, idx + 1)))
{
/* Skip labels until the last of the group. */
do {
++idx;
} while (idx < n
&& CASE_LABEL (cl) == CASE_LABEL (TREE_VEC_ELT (vec2,
idx)));
--idx;
When we reach the outer if, idx == 3 and n == 5. We go around twice, but idx
goes up to 7.
It looks like a loop optimization issue:
0x84fa0fd <find_switch_asserts+1309>: lea 0x2(%edi),%esi
0x84fa100 <find_switch_asserts+1312>: mov -0x40(%ebp),%edi
0x84fa103 <find_switch_asserts+1315>: cmp -0x3c(%ebp),%edi
0x84fa106 <find_switch_asserts+1318>: mov %esi,-0x40(%ebp)
0x84fa109 <find_switch_asserts+1321>: jb 0x84fa080
<find_switch_asserts+1184>
0x84fa10f <find_switch_asserts+1327>: mov -0x38(%ebp),%ecx
0x84fa112 <find_switch_asserts+1330>: dec %esi
0x84fa113 <find_switch_asserts+1331>: mov %esi,-0x40(%ebp)
-0x40(%ebp) is idx, and idx+1 is in %edi before the above code.
--
Summary: Cross-compilers built with GCC 3.4 do not work
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37086
