https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77826
Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2016-10-03 CC| |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Started with r240291. I think the problem is either in the /* (X | Y) ^ X -> Y & ~ X*/ (simplify (bit_xor:c (convert? (bit_ior:c @0 @1)) (convert? @0)) (if (tree_nop_conversion_p (type, TREE_TYPE (@0))) (convert (bit_and @1 (bit_not @0))))) simplifier or in the infrastructure. _3 = *v0_14(D); _4 = (long unsigned int) q2_11(D); _5 = _3 | _4; *v0_14(D) = _5; _7 = (unsigned int) _5; _9 = q2.0_1 ^ _7; The xor is done in unsigned int type, while ior is done in unsigned long int type, and evrp is trying to valueize q2_11(D) as 1. As it is valueized as 1 and operand_equal_p is true for 1U and 1UL, we seem to end up with @0 being 1U (rather than 1UL), while @1 is unsigned long variable. --- match.pd.jj 2016-09-29 22:53:14.000000000 +0200 +++ match.pd 2016-10-03 16:04:50.905185018 +0200 @@ -707,8 +707,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) /* (X | Y) ^ X -> Y & ~ X*/ (simplify (bit_xor:c (convert? (bit_ior:c @0 @1)) (convert? @0)) - (if (tree_nop_conversion_p (type, TREE_TYPE (@0))) - (convert (bit_and @1 (bit_not @0))))) + (if (tree_nop_conversion_p (type, TREE_TYPE (@1))) + (with { tree itype = TREE_TYPE (@1); } + (convert (bit_and @1 (bit_not (convert:itype @0))))))) /* Convert ~X ^ ~Y to X ^ Y. */ (simplify fixes the ICE, but I'm not sure if it is the right fix. Plus, there are various other simplifications which use (convert? @[0-9]) together with the same @[0-9] outside of the convert that could potentially have the same problem.