https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100604
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to dragan.mladjenovic from comment #2) > It seems so. Something like this helps in this case: > > diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c > index 07e908624a0..a102a9288c5 100644 > --- a/gcc/emit-rtl.c > +++ b/gcc/emit-rtl.c > @@ -2385,7 +2385,7 @@ adjust_address_1 (rtx memref, machine_mode mode, > poly_int64 offset, > if (GET_MODE (memref) != BLKmode > && GET_CODE (addr) == LO_SUM > && known_in_range_p (offset, > - 0, (GET_MODE_ALIGNMENT (GET_MODE (memref)) > + 0, (MIN (GET_MODE_ALIGNMENT (GET_MODE > (memref)), attrs.align) > / BITS_PER_UNIT))) > addr = gen_rtx_LO_SUM (address_mode, XEXP (addr, 0), > plus_constant (address_mode, > > Don't know which one to trust. The memref has SImode. Caller wants to create > HImode one. The attrs.align matches that of HImode. on a strict-align target if the MEM has SImode it should be aligned to the SImode alignment. Of course generally you should never look at GET_MODE_ALIGNMENT but use attrs.align unconditionally (aka MEM_ALIGN). Now the question is where the HImode aligned MEM:SI comes from for a strict-alignment target. That said, unconditionally using attrs.align looks like the correct fix.
