On 02/05/13 07:43, Ye Joey wrote:
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
Ok by me unless RM's object. It's been on trunk long enough and hasn't
caused any issues that I'm aware of.
Thanks for bringing this up. It looks like it slipped through the cracks
when I left Linaro.
regards
Ramana
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.
