[Bug middle-end/79220] missing -Wstringop-overflow= on a memcpy overflow with a small power-of-2 size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79220 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Known to work||9.0 Resolution|--- |FIXED Target Milestone|--- |9.0 Known to fail||7.3.0, 8.2.0 --- Comment #6 from Martin Sebor --- GCC 9 diagnoses both calls with -Warray-bounds. With it disabled, it then issues the expected -Wstringop-overflow: $ gcc -O2 -S -Wno-array-bounds t.c t.c: In function ‘f’: t.c:7:3: warning: ‘memcpy’ writing 8 bytes into a region of size 3 overflows the destination [-Wstringop-overflow=] 7 | memcpy (d, "0123456789", 8); | ^~~ t.c: In function ‘g’: t.c:12:3: warning: ‘memcpy’ writing 8 bytes into a region of size 3 overflows the destination [-Wstringop-overflow=] 12 | memcpy (d, s, 8); | ^~~~ This was fixed for GCC 9 in r268037.
[Bug middle-end/79220] missing -Wstringop-overflow= on a memcpy overflow with a small power-of-2 size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79220 --- Comment #5 from Eric Gallager --- (In reply to Martin Sebor from comment #4) > As an aside, the -Wstringop-overflow for f() will disappear if/when the > patch submitted for bug 83508 is committed. > The patch for bug 83508 was committed as r256683
[Bug middle-end/79220] missing -Wstringop-overflow= on a memcpy overflow with a small power-of-2 size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79220 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=83508 --- Comment #4 from Martin Sebor --- In GCC 8.0 the overflow is diagnosed in both functions. In f() by -Wstringop-overflow as before, and in both functions (perhaps surprisingly) by the newly enhanced -Warray-bounds warning (r255755). There is still no -Wstringop-overflow for g() so the limitation hasn't really been removed yet and this bug should stay open until it is, and until the overflow in g() is diagnosed -Wstringop-overflow when -Warray-bounds is disabled. As an aside, the -Wstringop-overflow for f() will disappear if/when the patch submitted for bug 83508 is committed. pr79220.c: In function ‘g’: pr79220.c:12:3: warning: ‘memcpy’ forming offset [4, 8] is out of the bounds [0, 3] of object ‘d’ with type ‘char[3]’ [-Warray-bounds] memcpy (d, s, 8); ^~~~ pr79220.c:3:6: note: ‘d’ declared here char d[3]; ^ pr79220.c: In function ‘f’: pr79220.c:7:3: warning: ‘memcpy’ forming offset [4, 8] is out of the bounds [0, 3] of object ‘d’ with type ‘char[3]’ [-Warray-bounds] memcpy (d, "0123456789", 8); ^~~ pr79220.c:3:6: note: ‘d’ declared here char d[3]; ^ pr79220.c:7:3: warning: ‘memcpy’ writing 8 bytes into a region of size 3 overflows the destination [-Wstringop-overflow=] memcpy (d, "0123456789", 8); ^~~
[Bug middle-end/79220] missing -Wstringop-overflow= on a memcpy overflow with a small power-of-2 size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79220
Martin Sebor changed:
What|Removed |Added
Summary|missing |missing
|-Wstringop-overflow= on a |-Wstringop-overflow= on a
|memcpy overflow |memcpy overflow with a
||small power-of-2 size
--- Comment #3 from Martin Sebor ---
The cause is of the missing warning is the folder
(gimple_fold_builtin_memory_op in gimple-fold.c) folding all copies with
power-of-two sizes less than MOVE_MAX, with no checking (see below). MOVE_MAX
is typically 8 or 8 but on some targets, including x86_64, it's as much as 16.
Although some basic simple checking could be done there, e.g., on arrays of
known size, the folder runs before the full object size information is
available and deferring the folding until it apparently isn't desirable.
/* If we can perform the copy efficiently with first doing all loads
and then all stores inline it that way. Currently efficiently
means that we can load all the memory into a single integer
register which is what MOVE_MAX gives us. */
src_align = get_pointer_alignment (src);
dest_align = get_pointer_alignment (dest);
if (tree_fits_uhwi_p (len)
&& compare_tree_int (len, MOVE_MAX) <= 0
/* ??? Don't transform copies from strings with known length this
confuses the tree-ssa-strlen.c. This doesn't handle
the case in gcc.dg/strlenopt-8.c which is XFAILed for that
reason. */
&& !c_strlen (src, 2))
{
unsigned ilen = tree_to_uhwi (len);
if (pow2p_hwi (ilen))
{
[Bug middle-end/79220] missing -Wstringop-overflow= on a memcpy overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79220 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-30 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Gallager --- Confirmed.
[Bug middle-end/79220] missing -Wstringop-overflow= on a memcpy overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79220 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Host||77799 --- Comment #1 from Martin Sebor --- See also bug 77799 for a similar problem involving sprintf.
