https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100263
--- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > I did a quick test by using instead > > diff --git a/gcc/postreload.c b/gcc/postreload.c > index dc67643384d..64297be2c45 100644 > --- a/gcc/postreload.c > +++ b/gcc/postreload.c > @@ -1732,12 +1732,7 @@ move2add_valid_value_p (int regno, scalar_int_mode > mode) > (REG:reg_mode[regno] regno). Now, for big endian, the starting > regno of the lowpart might be different. */ > poly_int64 s_off = subreg_lowpart_offset (mode, old_mode); > - s_off = subreg_regno_offset (regno, old_mode, s_off, mode); > - if (maybe_ne (s_off, 0)) > - /* We could in principle adjust regno, check reg_mode[regno] to be > - BLKmode, and return s_off to the caller (vs. -1 for failure), > - but we currently have no callers that could make use of this > - information. */ > + if (simplify_subreg_regno (regno, old_mode, s_off, mode) < 0) > return false; > } > > which works at least for the example (haven't done a bootstrap nor regtest > yet). However, I'm still wondering whether subreg_get_info is supposed to > return with a zero offset in cases like this? Any thoughts? See the head comment of subreg_get_info, especially at the end. We still need to check that the regno offset is zero since we reuse the same reg, but we also need to check targetm.hard_regno_mode_ok (regno, mode) here.
