http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46723
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to work|4.6.0 |
Summary|[4.5 Regression] internal |[4.5/4.6 Regression]
|compiler error: in |internal compiler error: in
|get_initial_def_for_inducti |get_initial_def_for_inducti
|on, at |on, at
|tree-vect-loop.c:2431 |tree-vect-loop.c:2431
Known to fail| |4.6.0
--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-01
15:32:55 UTC ---
C testcase that also ICEs on trunk:
short *m;
void test()
{
short x = 128;
unsigned int i;
for (i = 0; i < 128; ++i, x = (unsigned short)x + 1)
m[i] = x;
}
we are confused wrt the address arithmetic in
D.2720_6 = (long unsigned int) i_20;
D.2721_7 = D.2720_6 * 2;
D.2722_8 = pretmp.6_18 + D.2721_7;
*D.2722_8 = x_19;
and don't ICE with
short m[128];
which just gives us m[i_20] = x_19;
The access function that isn't a simple iv evolution is:
(short int) {(short unsigned int) x_50, +, 1}_1
At analysis time (in the not copied loop) we analyse it to
{128, +, 1}_1
instead as the loop bound is now non-constant after peeling a prologue:
<bb 3>:
# x_19 = PHI <x_12(4), x_50(22)>
# i_20 = PHI <i_9(4), i_52(22)>
# ivtmp.14_5 = PHI <ivtmp.14_27(4), ivtmp.14_55(22)>
D.2690_6 = (long unsigned int) i_20;
D.2691_7 = D.2690_6 * 2;
D.2692_8 = pretmp.6_18 + D.2691_7;
*D.2692_8 = x_19;
i_9 = i_20 + 1;
x.1_10 = (short unsigned int) x_19;
D.2694_11 = x.1_10 + 1;
x_12 = (short int) D.2694_11;
ivtmp.14_27 = ivtmp.14_5 - 1;
if (ivtmp.14_27 != 0)
goto <bb 4>;
else
goto <bb 19>;
in principle we can deal with that evolution just fine, but this
discrepancy analysis vs. transformation time doesn't look too good.
