https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dmalcolm at gcc dot gnu.org
Assignee|msebor at gcc dot gnu.org |law at redhat dot com
Summary|False positive from |Improve (or eliminate)
|-Wstringop-overflow on |diagnostics related to loop
|simple std::vector code |distribution
--- Comment #12 from Jeffrey A. Law <law at redhat dot com> ---
I was looking at this again tonight, and I clearly missed the interaction
between known ranges and the overflow check.
If we look at the .vrp1 dump we see this overflow check in bb16:
23 = ASSERT_EXPR <_13, _13 > 2>;
_1 = _23 + 18446744073709551614;
if (_1 > _23)
goto <bb 17>; [33.00%]
else
goto <bb 41>; [67.00%]
This is a controlling condition for the clearing loop which ldist will turn
into a memset.
The range for _23 is:
(gdb) p debug_value_range (get_value_range (gimple_cond_rhs (stmt)))
[3, +INF] EQUIVALENCES: { _13 } (1 elements)
Exactly what we'd expect given the ASSERT_EXPR. So far so good.
The condition can be rewritten as _23 - 2 > _23, which is only going to be true
if _23 has the value 0 or 1. So we can deduce that the condition is always
false.
We're correctly identifying the test as an overflow check in VRP, but we're not
optimizing it. I think we just need to extend
vr_values::vrp_evaluate_conditional_warnv_with_ops and the right things should
just happen.
