https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121501
--- Comment #8 from Richard Sandiford <rsandifo at gcc dot gnu.org> --- (In reply to Segher Boessenkool from comment #7) > How does this ICE gen_rtx_SUBREG btw? Are some asserts in there stricter > than all other things in the compiler, maybe? Yeah, stricter than simplify_(gen_)subreg at least. simplify_subreg & co are passed a separate inner mode and so validation is based off that. Those functions can therefore cope with VOIDmode rtxes. But gen_rtx_SUBREG can only go off what GET_MODE says, and validate_subreg (rightly) rejects subregs of VOIDmode. Before https://gcc.gnu.org/cgit/gcc/commit/?id=8e3239e3e92f3c , simplify_gen_subreg would punt on all VOIDmode rtxes. But there was also a separate condition to reject CONST_SCALAR_INT_P if MODE_COMPOSITE_P. The patch dropped the MODE_COMPOSITE_P part, and since CONST_SCALAR_INT_P should cover all valid uses of VOIDmode in this context, it seemed better to drop the VOIDmode check rather than check VOIDmode and CONST_SCALAR_INT_P side-by-side. This PR shows that I shouldn't do that for the backport though :)
