Ramana,
This issue also impacts ldrexh/ldrexb, as assembler doesn't accept
ldrexh r1, [r0, #0]. May it be backported to 4.7 by now?
Thanks - Joey
On Tue, Jul 24, 2012 at 8:09 PM, Ramana Radhakrishnan
<ramana.radhakrish...@linaro.org> wrote:
> Hi ,
>
>
> While testing my neon intrinsics work with some testcases
> that I was writing up, I ran into PR54051 . The one change which is
> probably a bit long standing is the fact that for register only
> addressing modes i.e. something like mem (reg:SI) we were printing out
> addresses with an immediate of #0. Historically the reason for this
> appears to be to deal with an assembler bug of yesteryears where the
> assembler couldn't sometimes properly distinguish between auto-inc
> addressing forms and the register indirect addressing form which I'm
> informed is fixed. This patch has gone through a full test run with
> qemu in a cross environment with no regressions for armv7-a / neon /
> arm/ thumb with a v5t multilib for c, c++ .
>
> I intend to backport this to 4.7 as this is a regression compared to
> 4.6, after letting it be on trunk for a few days to see if the
> auto-testers pick anything else up unless there is an objection from
> anyone.
>
> regards
> Ramana
>
>
>
>
> PR target/54051
> * config/arm/arm.c (arm_print_operand_address): Remove superfluous
> printing of #0.
> * config/arm/neon.md ("neon_vld3_lane<mode>":VD): Remove alignment
> specifier.
> ("neon_vld3_lane<mode>":VMQ): Likewise.
> ("neon_vld3_dup<mode>":VDX): Likewise.
> ("neon_vst3_lane<mode>":VD): Likewise.
> ("neon_vst3_lane<mode>":VMQ): Likewise.
>
>
> PR target/54051
> * gcc.target/arm/pr54051.c: New.
> * gcc.target/arm/vfp-1.c: Adjust test.
