Hi,
PR48250 happens under TARGET_NEON, where DImode is included within the
valid NEON modes. This turns the range of legitimate constant indexes to
step-4 (coproc load/store), thus arm_legitimize_reload_address() when
trying to decompose the [reg+index] reload address into
[(reg+index_high)+index_low], can cause an ICE later when 'index_low'
part is not aligned to 4.

I'm not sure why the current DImode index is computed as:
low = ((val & 0xf) ^ 0x8) - 0x8;  the sign-extending into negative
values, then subtracting back, actually creates further off indexes.
e.g. in the supplied testcase, [sp+13] was turned into [(sp+16)-3].

My patch changes the index decomposing to a more straightforward way; it
also sort of outlines the way the other reload address indexes are
broken by using and-masks, is not the most effective.  The address is
computed by addition, subtracting away the parts to obtain low+high
should be the optimal way of giving the largest computable index range.

I have included a few Thumb-2 bits in the patch; I know currently
arm_legitimize_reload_address() is only used under TARGET_ARM, but I
guess it might eventually be turned into TARGET_32BIT.

Cross-tested on QEMU without regressions, is this okay?

Thanks,
Chung-Lin

2011-03-24  Chung-Lin Tang  <cltang@codesourcery.com>

	PR target/48250
	* config/arm/arm.c (arm_legitimize_reload_address): Adjust
	DImode constant index decomposing. Mask out lower 2-bits for
	NEON and Thumb-2.

	testsuite/
	* gcc.target/arm/pr48250.c: New.