http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423
--- Comment #29 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-08-10
13:26:52 UTC ---
(In reply to comment #28)
>
> This ICE does happen on trunk (rev190294). I have a testcase for it that I'm
> reducing. There was a second ICE introduced by 190259 as well.
>
> /home/ryan/ice2.i:9312:1: error: unrecognizable insn:
> }
> ^
> (insn 780 647 781 28 (set (reg:SI 530)
> (ashift:SI (reg:SI 147 t)
> (const_int 1 [0x1]))) /home/ryan/ice2.i:9270 -1
> (nil))
> /home/ryan/ice2.i:9312:1: internal compiler error: in extract_insn, at
> recog.c:2125
>
> Should I attach the testcases to this PR or open a new PR?
This left shift ICE looks like a problem I introduced with changes in PR 54089.
Please post the testcase for this in PR 54089.
BTW, I've confirmed my guess in comment #27 that the following function
int test00 (int tab[], int i)
{
return tab[i * 8192 + 4];
}
will currently ICE when compiled for -m2 and will produce potentially wrong
code around the T_REG for -m2a and -m3. Checking it out...
