https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-12-01
CC| |msebor at gcc dot gnu.org
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=79095
Ever confirmed|0 |1
--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
Confirmed (with -O3, the warning doesn't trigger at -O2 for me on x86_64).
There was a similar report last year involving vector (pr79095) that Jeff fixed
in r245434. Either the fix is incomplete or this case is sufficiently
different that the fix is not effective. The invalid memset in this case first
also appears in a dump of the ldist pass, same as in pr79095:
<bb 13> [local count: 357916946]:
_1 = _17 + 18446744073709551614;
if (_1 > _17)
goto <bb 14>; [33.00%]
else
goto <bb 30>; [67.00%]
<bb 14> [local count: 59056296]:
_83 = a$16_134 - a$8_73;
_84 = _83 /[ex] 4;
_85 = (long unsigned int) _84;
if (_85 > 18446744073709551613)
goto <bb 42>; [67.00%]
else
goto <bb 16>; [33.00%]
<bb 42> [local count: 39567718]:
__builtin_memset (a$8_73, 0, 18446744073709551608);
An alternate solution to trying to nail down all these cases in VRP is to
recognize calls with these excessive sizes either before they are introduced
and avoid introducing them, or afterwards and replace them with a trap. The
patch I had originally submitted for bug 79095
(https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01152.html) does that and it
eliminates this warning.
The missing location is due to the code that introduces the memset call
neglecting to set the location.
As for the name of the option, its name comes from the String handling section
in the C standard which defines both raw memory functions (e.g., memset) and
string functions (e.g., strcpy), all of them declared in <string.h>.
