https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112673
--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:eebcad0ac22010fc59de9d856bb02017fccab282 commit r14-5819-geebcad0ac22010fc59de9d856bb02017fccab282 Author: Jakub Jelinek <ja...@redhat.com> Date: Fri Nov 24 11:32:28 2023 +0100 match.pd: Avoid simplification into invalid BIT_FIELD_REFs [PR112673] The following testcase is lowered by the bitint lowering pass, then vectorizer vectorizes one of the loops in it, so we have vect__18.6_34 = VIEW_CONVERT_EXPR<vector(4) unsigned long>(x_35(D)); _8 = BIT_FIELD_REF <vect__18.6_34, 64, 0>; ... _18 = BIT_FIELD_REF <vect__18.6_34, 64, 64>; etc. where x_35(D) is _BitInt(256) argument. That is valid BIT_FIELD_REF, the first argument is a vector and it extracts the vector elements from it. Then comes forwprop4 and simplifies that using match.pd into _8 = (unsigned long) x_35(D); ... _18 = BIT_FIELD_REF <x_35(D), 64, 64>; and tree-cfg verification ICEs on the latter (though, even the first cast is kind of undesirable after bitint lowering, we want large/huge bitints lowered). The ICE is because if BIT_FIELD_REFs first argument has INTEGRAL_TYPE_P, we require type_has_mode_precision_p, but that is not the case of _BitInt(256), it has BLKmode. The following patch fixes it by doing the BIT_FIELD_REF with VCE to BIT_FIELD_REF simplification only if the result is valid. 2023-11-24 Jakub Jelinek <ja...@redhat.com> PR tree-optimization/112673 * match.pd (bit_field_ref (vce @0) -> bit_field_ref @0): Only simplify if either @0 doesn't have scalar integral type or if it has mode precision. * gcc.dg/pr112673.c: New test.
