https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68291
--- Comment #11 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > I'm not comfortable with your relaxing the assert in cfgexpand.c:set_rtl. > It means we could have a PARALLEL for a RESULT_DECL *and* other variables, > because of coalescing. Although we can deal with PARALLELs in a > RESULT_DECL, not all expanders will deal with them successfully, IIRC. Relaxing the assert is required by the ABI though, for vector types with BLKmode that are returned in multiple registers. The alternative would be to smuggle them temporarily into a single register with large integer mode, but that would be a little kludgy. Or to declare that vector types with BLKmode are not GIMPLE register types, but that looks overkill and undesirable in the end. > We should make sure the RESULT_DECL is not coalesced with other variables if > we > are to accept a PARALLEL there. It's not obvious to me that we already do > that, but maybe we do as a side effect of assigning other variables of the > same mode to BLKmode and thus to memory, so it might be that it's not a > problem, after all, but I'd rather have at least a comment in the assert > indicating that the intent of that case is to cover uncoalesced PARALLELs in > RESULT_DECLs only. If we did get coalescing, we would likely get expander > ICEs elsewhere. Yes, that's my thinking too, we'll get ICEs downstream if something is missing in the machinery. I'm going to add the comment.
