https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #24 from rdapp at linux dot vnet.ibm.com --- Created attachment 38775 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38775&action=edit Updated patch and test, match.pd/VRP (In reply to amker from comment #23) > Hmm, not sure if I mis-understood your point. > I think there is no *overflow* concept for a VR_RANGE (or a variable), > overflow is always a semantic concept for an (arithmetic) operation. Take > below loop as an example: > > unsigned int i; > for (i = 4; i != 2; i += 2) > { > //.... > } > > Variable i has VR_RANGE [0, MAX_VALUE - 1], but it does overflow in the loop. Yes, a variable by itself cannot overflow, only an operation can. VRP for example has a function extract_range_from_binary_expr_1 that performs some overflow checking internally. It does so by comparing the minima and maxima of the respective ranges from both operands. I assumed an overflow there would somehow be propagated into the ranges, hence the question how to access the cast expression in match.pd. Guess I was thinking too complicated, getting the range of both operands and checking if their common minimum is smaller than the maximum should suffice for now. Attached is the current version of the patch, no regressions on s390x and x86-64. The test could be made a bit more specific I suppose, currently it counts the number of "gimple_simplified"s.