On 06/11/15 10:46, Kyrill Tkachov wrote:
Hi all,
In this wrong-code PR the vector setmem expansion and
arm_block_set_aligned_vect in particular
use the wrong offset when calling adjust_automodify_address. In the attached
testcase during the
initial zeroing out we get two V16QI stores, but they both are recorded by
adjust_automodify_address
as modifying x+0 rather than x+0 and x+12 (the total size to be written is 28).
This led to the scheduling pass moving the store from "x.g = 2;" to before the
zeroing stores.
This patch fixes the problem by keeping track of the offset to which stores are
emitted and
passing it to adjust_automodify_address as appropriate.
From inspection I see arm_block_set_unaligned_vect also has this issue so I
performed the same
fix in that function as well.
Bootstrapped and tested on arm-none-linux-gnueabihf.
Ok for trunk?
This bug appears on GCC 5 too and I'm currently testing this patch there.
Ok to backport to GCC 5 as well?
Bootstrap and testing for arm-none-linux-gnueabihf on GCC 5 branch looks ok too.
Kyrill
Thanks,
Kyrill
2015-11-06 Kyrylo Tkachov <kyrylo.tkac...@arm.com>
PR target/68143
* config/arm/arm.c (arm_block_set_unaligned_vect): Keep track of
offset from dstbase and use it appropriately in
adjust_automodify_address.
(arm_block_set_aligned_vect): Likewise.
2015-11-06 Kyrylo Tkachov <kyrylo.tkac...@arm.com>
PR target/68143
* gcc.target/arm/pr68143_1.c: New test.
