apinski--- via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > From: Andrew Pinski <apin...@marvell.com> > > The problem here is with -mstrict-align, aarch64_expand_setmem needs > to check the alginment of the mode to make sure we can use it for > doing the stores. > > gcc/ChangeLog: > > PR target/103100 > * config/aarch64/aarch64.c (aarch64_expand_setmem): > Add check for alignment of the mode if STRICT_ALIGNMENT is true. > --- > gcc/config/aarch64/aarch64.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c > index fdf05505846..2c00583e12c 100644 > --- a/gcc/config/aarch64/aarch64.c > +++ b/gcc/config/aarch64/aarch64.c > @@ -23738,7 +23738,9 @@ aarch64_expand_setmem (rtx *operands) > over writing. */ > opt_scalar_int_mode mode_iter; > FOR_EACH_MODE_IN_CLASS (mode_iter, MODE_INT) > - if (GET_MODE_BITSIZE (mode_iter.require ()) <= MIN (n, copy_limit)) > + if (GET_MODE_BITSIZE (mode_iter.require ()) <= MIN (n, copy_limit) > + && (!STRICT_ALIGNMENT > + || MEM_ALIGN (dst) >= GET_MODE_ALIGNMENT (mode_iter.require > ())))
Sorry for the slow review. I think instead we should have keep track of the alignment of the start byte. This will be MEM_ALIGN for the first iteration but could decrease after writing some bytes. The net effect should be the same in practice. It just seems more robust. Thanks, Richard > cur_mode = mode_iter.require (); > > gcc_assert (cur_mode != BLKmode);
