[PR 54051 ARM] Fix alignment specifier alignment information for ARM.
Tue Feb 5 14:01:00 GMT 2013
On 02/05/13 07:43, Ye Joey wrote:
> 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.
> On Tue, Jul 24, 2012 at 8:09 PM, Ramana Radhakrishnan
> <email@example.com> 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
>> 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
>> ("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.
More information about the Gcc-patches