* [Bug middle-end/109449] [11/12/13 Regression] false positive stringop-overflow
2023-04-08 7:35 [Bug middle-end/109449] New: false positive stringop-overflow pionere at freemail dot hu
` (2 preceding siblings ...)
2023-04-09 6:32 ` pionere at freemail dot hu
@ 2023-04-12 13:54 ` rguenth at gcc dot gnu.org
2023-04-13 7:19 ` rguenth at gcc dot gnu.org
2023-05-29 10:08 ` [Bug middle-end/109449] [11/12/13/14 " jakub at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-04-12 13:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109449
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Known to fail| |11.3.0
Priority|P3 |P2
Ever confirmed|0 |1
CC| |jakub at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Summary|false positive |[11/12/13 Regression] false
|stringop-overflow |positive stringop-overflow
Known to work| |10.4.0
Last reconfirmed| |2023-04-12
Target Milestone|--- |11.4
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think the code is correct. What we see is for example
_11 = (int) ivtmp.16_45;
_12 = (sizetype) _11;
_13 = &drlg.D.2834.transDirMap[0][0] + _12;
*_13 = tpm_21;
and it seems to be confused about the computed object size from
pointer-query.cc
via handle_mem_ref of *_13 which eventually computes the size of
&drlg.D.2834.transDirMap[0][0] and then eventually does
static bool
handle_array_ref (tree aref, gimple *stmt, bool addr, int ostype,
access_ref *pref, ssa_name_limit_t &snlim,
pointer_query *qry)
{
...
if (ostype && TREE_CODE (eltype) == ARRAY_TYPE)
{
/* Except for the permissive raw memory functions which use
the size of the whole object determined above, use the size
of the referenced array. Because the overall offset is from
the beginning of the complete array object add this overall
offset to the size of array. */
offset_int sizrng[2] =
{
pref->offrng[0] + orng[0] + sz,
pref->offrng[1] + orng[1] + sz
};
if (sizrng[1] < sizrng[0])
std::swap (sizrng[0], sizrng[1]);
if (sizrng[0] >= 0 && sizrng[0] <= pref->sizrng[0])
pref->sizrng[0] = sizrng[0];
if (sizrng[1] >= 0 && sizrng[1] <= pref->sizrng[1])
pref->sizrng[1] = sizrng[1];
thus it thinks we offset transDirMap[0] and thus run out of that bound.
That's wishful thinking outside of any coding reality. The following
fixes all of the bogus diagnostics. But will likely regress some of the
testsuite, will check what. There are likely duplicates of this bug.
I think it's definitely valid C and only in violation of some stricter
security-style coding rules and thus definitely shouldn't behave like this
by default.
diff --git a/gcc/pointer-query.cc b/gcc/pointer-query.cc
index 5b05e9bedf8..067e264fddb 100644
--- a/gcc/pointer-query.cc
+++ b/gcc/pointer-query.cc
@@ -1834,7 +1834,7 @@ handle_array_ref (tree aref, gimple *stmt, bool addr, int
ostype,
orng[0] *= sz;
orng[1] *= sz;
- if (ostype && TREE_CODE (eltype) == ARRAY_TYPE)
+ if (!addr && ostype && TREE_CODE (eltype) == ARRAY_TYPE)
{
/* Except for the permissive raw memory functions which use
the size of the whole object determined above, use the size
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/109449] [11/12/13 Regression] false positive stringop-overflow
2023-04-08 7:35 [Bug middle-end/109449] New: false positive stringop-overflow pionere at freemail dot hu
` (3 preceding siblings ...)
2023-04-12 13:54 ` [Bug middle-end/109449] [11/12/13 Regression] " rguenth at gcc dot gnu.org
@ 2023-04-13 7:19 ` rguenth at gcc dot gnu.org
2023-05-29 10:08 ` [Bug middle-end/109449] [11/12/13/14 " jakub at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-04-13 7:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109449
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
As expected that causes
FAIL: c-c++-common/Wstringop-truncation.c -std=gnu++98 bug 77293 (test for
warn
ings, line 271)
FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings,
lin
e 49)
FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings,
lin
e 50)
FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings,
lin
e 51)
FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings,
lin
e 55)
FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings,
line 56)
FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings,
line 57)
FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings,
line 61)
FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings,
line 62)
FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings,
line 63)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 28)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 29)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 30)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 50)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 51)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 52)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 53)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 127)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 128)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 129)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 131)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 132)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 135)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 136)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 137)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 139)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 140)
FAIL: gcc.dg/Wstringop-overflow-37.c note (test for warnings, line 194)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 195)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 213)
FAIL: gcc.dg/Wstringop-overflow-37.c note (test for warnings, line 230)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 231)
FAIL: gcc.dg/Wstringop-overflow-37.c note (test for warnings, line 236)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 237)
FAIL: gcc.dg/Wstringop-overflow-37.c (test for excess errors)
FAIL: gcc.dg/Wstringop-overflow-40.c (test for warnings, line 103)
FAIL: gcc.dg/Wstringop-overflow-40.c (test for excess errors)
FAIL: gcc.dg/pr56837.c scan-tree-dump-times optimized "memset ..c, 68, 16384.;"
1
FAIL: gcc.dg/warn-strnlen-no-nul.c (test for warnings, line 150)
FAIL: gcc.dg/warn-strnlen-no-nul.c (test for warnings, line 154)
FAIL: c-c++-common/Wstringop-truncation.c -Wc++-compat bug 77293 (test for
warnings, line 271)
as those all explicitely test for this "misbehavior" (aka _FORTIFY_SOURCE=2).
Note -Wstringop-overflow=1 diagnoses this the same.
The workaround in the source would be to use for example
uint8_t *tdp = (uint8_t *)drlg.transDirMap;
or simply use two-dimensional array accesses directly to transDirMap.
So as a summary, the diagnostic works this way by design (a design not
everyone agrees to, me included, esp. for the case of multidimensional
arrays).
^ permalink raw reply [flat|nested] 7+ messages in thread