https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095
--- Comment #9 from Jeffrey A. Law <law at redhat dot com> --- Sigh. I was looking at the wrong dump. We don't need to deal with ADD_OVERFLOW. Looking at the real test for this BZ, the guarding block has the right form: <bb 3> [100.00%]: _7 = MEM[(unsigned int * *)&v]; _8 = MEM[(unsigned int * *)&v + 8B]; _9 = (long int) _8; _10 = (long int) _7; _11 = _9 - _10; _12 = _11 /[ex] 4; _13 = (long unsigned int) _12; _1 = _13 + 18446744073709551615; if (_1 > _13) goto <bb 4>; [29.56%] else goto <bb 28>; [70.44%] We can easily see the condition can be rewritten as (_13 == 0) The problem is we don't have enough information about _13 to evaluate that at compile time so my VRP hack doesn't optimize it in vrp_evaluate_conditional. But I would probably claim that simplification from a 2-operand relational to a zero/not-zero test is in and of itself a good thing irrespective of the single_use issues and thus we should go ahead and turn it into an equality test. If I manually transform that test, 2 of the 3 warnings go away. While looking through the dumps I saw another conditional that has the form above, *but* it's obfuscated by ASSERT_EXPRs. I believe if we transform that one as well, there's a good chance the last warning will be eliminated. So when I look at the whole, I think there's really two changes that need to be made. First, a special cased match.pd pattern to detect these overflow tests that collapse into a zero/not-zero comparison and apply them regardless of the single_use property. That should detect both cases in the original testcase and hopefully remove all 3 of the warnings. Second, vrp_evaluate_conditional ought detect when there's a more general simplified form (which wasn't simplified due to the single_use property) and use that simplified form when trying to determine if a conditional is compile-time determinable. I've got a prototype for this. THe question is whether or not it applies often enough to matter in practice. I'll have to do more instrumentation.
