The fault is correct - the RTL attempts to do a sign extending load from an address +1665 bytes, where ARM mode supports offsets of 0 to 255 bytes. Thumb-2 supports 0 to 4095 bytes.
The work-around is to compile at -O0. The fault also exists in gcc-4.6.1 and trunk r178025. It does not exist in gcc-4.5.3.
I've set it to medium priority as it is a ftbfs, a (mediocre) work-around exists, this is a significant package, and the fault exists upstream.
Thank you for the bug report. I've confirmed this with gcc-linaro- 4.6-2011. 08 on ARM:
michaelh@ ursa1:~ /linaro/ bugs$ /tools/ toolchains/ arch/armv7l/ gcc-linaro- 4.6-2011. 08-armv7l- natty-cbuild162 -ursa1- cortexa9r1/ bin/gcc -marm -O2 -c lp838994.i
(sign_ extend: SI (mem/s:QI (plus:SI (reg:SI 0 r0)
( const_int 1665 [0x681])) [0 my_perl_ 52(D)-> Iutf8cache+ 0 S1 A8]))) mg.c:891 -1
mg.c: In function 'Perl_magic_get':
mg.c:1088:1: error: unrecognizable insn:
(insn 1520 1519 1521 65 (set (reg:SI 2 r2)
(nil))
mg.c:1088:1: internal compiler error: in extract_insn, at recog.c:2113
The fault is correct - the RTL attempts to do a sign extending load from an address +1665 bytes, where ARM mode supports offsets of 0 to 255 bytes. Thumb-2 supports 0 to 4095 bytes.
The work-around is to compile at -O0. The fault also exists in gcc-4.6.1 and trunk r178025. It does not exist in gcc-4.5.3.
I've set it to medium priority as it is a ftbfs, a (mediocre) work-around exists, this is a significant package, and the fault exists upstream.