https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #26 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> --- But this is how technical debt builds up. We'd be making a change that doesn't match the type system, and that we know to be wrong in principle. And we'd be making it with no realistic prospect that it will be cleaned up later. > Yes. I am also worrying about GIMPLE_FOLD stuff will check all arguments > type are compatible for COND_LEN_xxx in the future (Currently, it's obviously > not checking this). Then, it will cause ICE. Yeah. But like I say, I don't think that's the most worrying scenario. For me the most worrying scenario is that a match.pd fold will say that: (cond_len all-false a b c len bias) folds to c without checking whether c is compatible with the return type. And IMO it shouldn't need to check that the type is compatible. If a rule like that triggers after this patch goes in, the pressure will be to continue to support the hack and add workarounds for it.
