| Message ID | 4C2F1DBF.8060500@codesourcery.com |
|---|---|
| State | New |
| Headers | show |
off topic.. On 3 Jul 2010, at 12:23, Bernd Schmidt wrote: > Regression tested on: > Target is arm-none-linux-gnueabi > Host is i686-pc-linux-gnu > > Schedule of variations: > qemu-system-armv7/arch=armv7-a/thumb > qemu-system-armv7/thumb > qemu-system-armv7 is there a HOW-to for this setup somewhere [preferably with a downloadable qemu image ;-)] ? (I've built the cross-tools - but, obviously, arm testing is pretty limited with the gcc simulator). thanks Iain
On Sat, 2010-07-03 at 13:23 +0200, Bernd Schmidt wrote: > This fixes an ICE which is caused by reload generating an invalid > instruction. While reloading a complex addressing mode, it generates > > (insn 98 55 59 2 pr44788.c:6 (set (reg:SI 5 r5) > (plus:SI (mult:SI (reg/v:SI 5 r5 [orig:183 t ] [183]) > (const_int 4 [0x4])) > (reg/f:SI 13 sp))) 661 {*thumb2_arith_shiftsi} (nil)) > > There isn't actually anything wrong with this, except the pattern > doesn't allow the stack pointer - but the machine does. Hence, the > following patch. > > I've added the testcase in two places; the copy in gcc.target uses the > compilation flags in the PR (which are necessary to reproduce the bug). > > Regression tested on: > Target is arm-none-linux-gnueabi > Host is i686-pc-linux-gnu > > Schedule of variations: > qemu-system-armv7/arch=armv7-a/thumb > qemu-system-armv7/thumb > qemu-system-armv7 > > Ok? > > > Bernd OK. R.
Index: testsuite/gcc.c-torture/compile/pr44788.c =================================================================== --- testsuite/gcc.c-torture/compile/pr44788.c (revision 0) +++ testsuite/gcc.c-torture/compile/pr44788.c (revision 0) @@ -0,0 +1,8 @@ +void joint_decode(float* mlt_buffer1, int t) { + int i; + float decode_buffer[1060]; + foo(decode_buffer); + for (i=0; i<10 ; i++) { + mlt_buffer1[i] = i * decode_buffer[t]; + } +} Index: testsuite/gcc.target/arm/pr44788.c =================================================================== --- testsuite/gcc.target/arm/pr44788.c (revision 0) +++ testsuite/gcc.target/arm/pr44788.c (revision 0) @@ -0,0 +1,12 @@ +/* { dg-do compile } */ +/* { dg-require-effective-target arm_thumb2_ok } */ +/* { dg-options "-Os -fno-strict-aliasing -fPIC -mthumb -march=armv7-a -mfpu=vfp3 -mfloat-abi=softfp" } */ + +void joint_decode(float* mlt_buffer1, int t) { + int i; + float decode_buffer[1060]; + foo(decode_buffer); + for (i=0; i<10 ; i++) { + mlt_buffer1[i] = i * decode_buffer[t]; + } +} Index: config/arm/thumb2.md =================================================================== --- config/arm/thumb2.md (revision 161725) +++ config/arm/thumb2.md (working copy) @@ -467,7 +467,7 @@ (define_insn "*thumb2_arith_shiftsi" [(match_operator:SI 3 "shift_operator" [(match_operand:SI 4 "s_register_operand" "r") (match_operand:SI 5 "const_int_operand" "M")]) - (match_operand:SI 2 "s_register_operand" "r")]))] + (match_operand:SI 2 "s_register_operand" "rk")]))] "TARGET_THUMB2" "%i1%?\\t%0, %2, %4%S3" [(set_attr "predicable" "yes") Index: config/arm/arm.md =================================================================== --- config/arm/arm.md (revision 161726) +++ config/arm/arm.md (working copy) @@ -9006,7 +9006,7 @@ (define_insn "*arith_shiftsi" [(match_operator:SI 3 "shift_operator" [(match_operand:SI 4 "s_register_operand" "r") (match_operand:SI 5 "reg_or_int_operand" "rI")]) - (match_operand:SI 2 "s_register_operand" "r")]))] + (match_operand:SI 2 "s_register_operand" "rk")]))] "TARGET_ARM" "%i1%?\\t%0, %2, %4%S3" [(set_attr "predicable" "yes")
This fixes an ICE which is caused by reload generating an invalid instruction. While reloading a complex addressing mode, it generates (insn 98 55 59 2 pr44788.c:6 (set (reg:SI 5 r5) (plus:SI (mult:SI (reg/v:SI 5 r5 [orig:183 t ] [183]) (const_int 4 [0x4])) (reg/f:SI 13 sp))) 661 {*thumb2_arith_shiftsi} (nil)) There isn't actually anything wrong with this, except the pattern doesn't allow the stack pointer - but the machine does. Hence, the following patch. I've added the testcase in two places; the copy in gcc.target uses the compilation flags in the PR (which are necessary to reproduce the bug). Regression tested on: Target is arm-none-linux-gnueabi Host is i686-pc-linux-gnu Schedule of variations: qemu-system-armv7/arch=armv7-a/thumb qemu-system-armv7/thumb qemu-system-armv7 Ok? Bernd PR rtl-optimization/44787 * config/arm/arm.md (arith_shiftsi): Allow stack pointer in operand 2. * config/arm/thumb2.md (thumb2_arith_shiftsi): Likewise. PR rtl-optimization/44787 * gcc.c-torture/compile/pr44788.c: New test. * gcc.target/arm/pr44788.c: New test.