when building opensp with gcc-4.1.1 and on alpha, gcc ICEs:
ice.ii: In function 'void (int, int)':
ice.ii:13: error: unrecognizable insn:
(insn 23 22 24 2 (set (reg:DI 84)
(leu:DI (const_int 0 [0x0])
(const_int 4 [0x4]))) -1 (nil)
(nil))
ice.ii:13: internal compiler error: in extract_insn, at recog.c:2084
verified on Gentoo and Debian that 4.0.3 works, 4.1.1 fails, 4.2 works

Comment #1 from vapier at gentoo dot org 2006-07-14 02:42
Created an attachment (id=11887)
()
PR28376.ii

Comment #2 from pinskia at gcc dot gnu dot org 2006-07-14 03:45
(In reply to comment #0)
ice.ii:13: error: unrecognizable insn:
(insn 23 22 24 2 (set (reg:DI 84)
(leu:DI (const_int 0 [0x0])
(const_int 4 [0x4]))) -1 (nil)
(nil))

This should never have showed up as that is a constant. I wonder how much
related to PR13031 this really is.

Comment #3 from falk at debian dot org 2006-07-14 08:08
This simplified test case ICEs already at :

static const long unsigned sizes[] = { 4, 8 };
static long unsigned maxSize(const long unsigned *v) {
unsigned long max = 0;
unsigned long i = 0;
for (; i < 2; i++)
if (v[i] max)
max = v[i];
return max;
}
unsigned long a = maxSize(sizes);

00.expand already contains the unfolded leu. I suppose this is not valid RTL?

4.2 does not exhibit this bug.

Comment #4 from pinskia at gcc dot gnu dot org 2006-07-14 08:20
(In reply to comment #3)
This simplified test case ICEs already at :

00.expand already contains the unfolded leu. I suppose this is not valid RTL?

I think this is a case where we unroll the loop but don't do store-CCP after
the unroller so we can get expand looks into sizes for the value but then we
don't call simplify-rtx before emitting (which seems wrong).