[Bug c++/79095] [7 regression] spurious stringop-overflow warning

[law at redhat dot com]

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.