[Bug middle-end/96988] Bad/missing warnings when returning a temporary from an inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96988
Martin Sebor changed:
What|Removed |Added
Component|c++ |middle-end
CC||msebor at gcc dot gnu.org
Blocks||90556
--- Comment #3 from Martin Sebor ---
In the test cases in comment #0 the -Wreturn-local-addr warning is defeated by
inlining. By the time the warning sees the program the body of the static
function has been inlined into its caller and replaced with a read from an
uninitialized variable:
;; Function bar (bar, funcdef_no=1, decl_uid=1981, cgraph_uid=2,
symbol_order=1)
int bar ()
{
int a;
[local count: 1073741824]:
return a_2(D);
}
Running a subset of the -Wreturn-local-addr warning earlier, before inlining,
would make it possible to detect the problem in the C test case but not the one
in the more interesting C++ test case. That one depends on inlining, but it
would have be diagnosed during inlining. After the callee is inlined it's too
late.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90556
[Bug 90556] [meta-bug] bogus/missing -Wreturn-local-addr
[Bug c/63272] GCC should warn when using pointer to dead scoped variable within the same function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63272 Martin Sebor changed: What|Removed |Added CC||oleg.pekar.2017 at gmail dot com --- Comment #6 from Martin Sebor --- *** Bug 98901 has been marked as a duplicate of this bug. ***
[Bug middle-end/98901] missing warning passing a dangling pointer to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98901 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Martin Sebor --- With the -Wdangling-pointer patch (see bug 63272 comment 5) GCC diagnoses the problem in both the test case in attachment 50096: test2.c: In function ‘main’: test2.c:34:5: warning: using dangling pointer ‘p’ to ‘x’ [-Wdangling-pointer=] test2.c:29:13: note: ‘x’ declared here test2.c:33:5: warning: using dangling pointer ‘p’ to ‘x’ [-Wdangling-pointer=] test2.c:29:13: note: ‘x’ declared here and the one in comment #1: $ gcc -O2 -S -Wall pr98901.c pr98901.c: In function ‘main’: pr98901.c:13:9: warning: using dangling pointer ‘p’ to ‘x’ [-Wdangling-pointer=] 13 | return *p; | ^~ pr98901.c:7:9: note: ‘x’ declared here 7 | int x = 0; | ^ pr98901.c:11:3: warning: using dangling pointer ‘p’ to ‘x’ [-Wdangling-pointer=] 11 | f (1, p); // missing warning | ^~~~ pr98901.c:7:9: note: ‘x’ declared here 7 | int x = 0; | ^ *** This bug has been marked as a duplicate of bug 63272 ***
[Bug c/103104] missing warning about superfluous forward declaration -Wsuperfluous-forward-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103104
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2021-12-16
CC||msebor at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Blocks|87403 |
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #2 from Martin Sebor ---
Based on the rather loose(*) description of -Wredundant-decls in the manual:
Warn if anything is declared more than once in the same scope, even in cases
where multiple declaration is valid and changes nothing.
I'd expect the warning to trigger but it doesn't, most likely because it only
triggers for the second and subsequent declaration that's not a definition. It
seems that this can be viewed as a request to enhance -Wredundant-decls to do
what's already documented to do.
Here's a test case:
$ cat a.c && gcc -O2 -S -Wall -Wextra -Wredundant-decls a.c
static void f (void);
static void f (void); // -Wredundant-decl
static void f (void) { }
static void g (void); // no warning
static void g (void) { }
void h (void)
{
f ();
g ();
}
a.c:2:13: warning: redundant redeclaration of ‘f’ [-Wredundant-decls]
2 | static void f (void); // -Wredundant-decl
| ^
a.c:1:13: note: previous declaration of ‘f’ with type ‘void(void)’
1 | static void f (void);
| ^
I say "loose" above because it suggests that the following should also be
diagnosed but aren't:
enum E;
enum E; // missing -Wredundant-decl
struct S;
struct S;// missing -Wredundant-decl
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug middle-end/101751] asan_test.C fails with excess error with glibc-2.34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101751 Martin Sebor changed: What|Removed |Added Component|testsuite |middle-end Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Sebor --- Fixed in GCC 12 and 11.
[Bug c/101604] [meta-bug] bogus/missing -Wvla-parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101604 Bug 101604 depends on bug 101289, which changed state. Bug 101289 Summary: [11 Regression] bogus -Wvla-paramater warning when using const for vla param https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101289 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/101289] [11 Regression] bogus -Wvla-paramater warning when using const for vla param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101289 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Martin Sebor --- Fixed.
[Bug c++/103703] ICE with -Wmismatched-tags with friends and templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103703 Martin Sebor changed: What|Removed |Added Target Milestone|--- |11.3
[Bug c++/103703] ICE with -Wmismatched-tags with friends and templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103703 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Martin Sebor --- Fixed on trunk and in GCC 11.
[Bug middle-end/102697] [12 Regression] overflow warning missing after -O2 vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102697
--- Comment #4 from Martin Sebor ---
The warning for the test in comment #0 fails to trigger because of the hack
below in pointer-query.cc:
/* A helper of compute_objsize_r() to determine the size from MEM_REF
MREF. Return true on success and false on failure. */
static bool
handle_mem_ref (tree mref, gimple *stmt, int ostype, access_ref *pref,
ssa_name_limit_t &snlim, pointer_query *qry)
{
gcc_assert (TREE_CODE (mref) == MEM_REF);
tree mreftype = TYPE_MAIN_VARIANT (TREE_TYPE (mref));
if (VECTOR_TYPE_P (mreftype))
{
/* Hack: Handle MEM_REFs of vector types as those to complete
objects; those may be synthesized from multiple assignments
to consecutive data members (see PR 93200 and 96963).
FIXME: Vectorized assignments should only be present after
vectorization so this hack is only necessary after it has
run and could be avoided in calls from prior passes (e.g.,
tree-ssa-strlen.c).
FIXME: Deal with this more generally, e.g., by marking up
such MEM_REFs at the time they're created. */
ostype = 0;
}
[Bug middle-end/101475] missing -Wstringop-overflow storing a compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101475 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-12-16 Ever confirmed|0 |1 Target Milestone|--- |12.0 Keywords||patch Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587033.html
[Bug testsuite/103751] FAIL: gcc.dg/Warray-bounds-48.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103751 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Martin Sebor --- Fixed.
[Bug testsuite/103751] FAIL: gcc.dg/Warray-bounds-48.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103751 Martin Sebor changed: What|Removed |Added Blocks|56456 | Keywords||diagnostic Target Milestone|--- |12.0 Ever confirmed|0 |1 Last reconfirmed||2021-12-16 Status|UNCONFIRMED |ASSIGNED Component|middle-end |testsuite Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- The reason for the unexpected warnings is that the test assumes that a struct with just two members, a 32-bit int followed by a 16-bit int, is padded to 64-bits. That a valid assumption on many but not all targets. The m68k-*-* target aligns 32-bit integers on a 16-bit boundary and so it doesn't add any tail padding to such a struct, so the warnings are valid. Let me fix the test. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 102722, which changed state. Bug 102722 Summary: [Disgnostic]Xpass for gcc.dg/Wstringop-overflow-68.c after O2 vectorization. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102722 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/101475] missing -Wstringop-overflow storing a compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101475 Martin Sebor changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #1 from Martin Sebor --- *** Bug 102722 has been marked as a duplicate of this bug. ***
[Bug middle-end/102722] [Disgnostic]Xpass for gcc.dg/Wstringop-overflow-68.c after O2 vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102722
Martin Sebor changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Target||sparc-sun-solaris2.11
Status|UNCONFIRMED |RESOLVED
Last reconfirmed||2021-12-16
CC||msebor at gcc dot gnu.org
Host|x86_64-pc-linux-gnu |
--- Comment #2 from Martin Sebor ---
The underlying problem behind the fails/xfails in the test boils down to
pr101475. Here's a small test case that shows what's going on. With an x86_64
native GCC 12 -Wstringop-overflow triggers for the overflow in fa4() but not
for the one in fa3(). The reason is the difference in the IL (the expected
instances of the warning are issued from tree-ssa-strlen.c): GCC 12 handles the
vectorized assignment in the latter but not the form in fa3(). The reason for
the missing warning is that for COMPONENT_REF, compute_objsize() only considers
the size of the sobobject and not also that of the complete object (like the
underlying buffer).
$ cat pr102722.c && gcc -O2 -S -fdump-tree-strlen=/dev/stdout pr102722.c
typedef struct AC3 { char a[3]; } AC3;
typedef struct AC4 { char a[4]; } AC4;
extern char a1[1];
void fa3 (void)
{
*(AC3*)a1 = (AC3) { 0, 1, 2 }; // { dg-warning "-Wstringop-overflow" }
}
void fa4 (void)
{
*(AC4*)a1 = (AC4) { 0, 1, 2, 3 }; // { dg-warning "-Wstringop-overflow" }
}
;; Function fa3 (fa3, funcdef_no=0, decl_uid=1985, cgraph_uid=1,
symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
void fa3 ()
{
[local count: 1073741824]:
MEM[(struct AC3 *)&a1].a[0] = 0;
MEM[(struct AC3 *)&a1].a[1] = 1;
MEM[(struct AC3 *)&a1].a[2] = 2;
return;
}
;; Function fa4 (fa4, funcdef_no=1, decl_uid=1989, cgraph_uid=2,
symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
pr102722.c: In function ‘fa4’:
pr102722.c:13:13: warning: writing 4 bytes into a region of size 1
[-Wstringop-overflow=]
13 | *(AC4*)a1 = (AC4) { 0, 1, 2, 3 }; // { dg-warning
"-Wstringop-overflow" }
| ~~^~
pr102722.c:4:13: note: destination object ‘a1’ of size 1
4 | extern char a1[1];
| ^~
void fa4 ()
{
char * vectp.10;
vector(4) char * vectp_a1.9;
[local count: 1073741824]:
MEM [(char *)&a1] = { 0, 1, 2, 3 };
return;
}
*** This bug has been marked as a duplicate of bug 101475 ***
[Bug testsuite/102944] Many gcc.dg/Wstringop-overflow-*.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102944 Martin Sebor changed: What|Removed |Added Ever confirmed|0 |1 CC||msebor at gcc dot gnu.org Last reconfirmed||2021-12-16 Status|UNCONFIRMED |WAITING --- Comment #5 from Martin Sebor --- I don't see any of the FAILs or XFAILs listed in comment #0 with cross compilers for any of the Targets. Can this report be resolved? I do see some unexpected failures with an m68k-unknown-linux-gnu cross in other tests. I opened pr103751 for those.
[Bug middle-end/103751] New: FAIL: gcc.dg/Warray-bounds-48.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103751
Bug ID: 103751
Summary: FAIL: gcc.dg/Warray-bounds-48.c (test for excess
errors)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The two tests below show a coupled of failures with the m68k-unknown-linux-gnu
cross:
Running /src/gcc/master/gcc/testsuite/gcc.dg/dg.exp ...
FAIL: gcc.dg/Warray-bounds-48-novec.c (test for excess errors)
FAIL: gcc.dg/Warray-bounds-48.c (test for excess errors)
=== gcc Summary ===
# of expected passes3555
# of unexpected failures2
# of expected failures 280
/ssd/build/m68k-unknown-linux-gnu/gcc-master/gcc/xgcc version 12.0.0 20211215
(experimental) (GCC)
Excess errors:
/src/gcc/master/gcc/testsuite/gcc.dg/Warray-bounds-48-novec.c:241:50: warning:
array subscript 3 is above array bounds of 'int16_t[1]' {aka 'short int[1]'}
[-Warray-bounds]
/src/gcc/master/gcc/testsuite/gcc.dg/Warray-bounds-48-novec.c:248:64: warning:
array subscript 4 is above array bounds of 'int16_t[1]' {aka 'short int[1]'}
[-Warray-bounds]
Excess errors:
/src/gcc/master/gcc/testsuite/gcc.dg/Warray-bounds-48.c:241:50: warning: array
subscript 3 is above array bounds of 'int16_t[1]' {aka 'short int[1]'}
[-Warray-bounds]
/src/gcc/master/gcc/testsuite/gcc.dg/Warray-bounds-48.c:248:64: warning: array
subscript 4 is above array bounds of 'int16_t[1]' {aka 'short int[1]'}
[-Warray-bounds]
[Bug sanitizer/91707] [10/11/12 Regression] spurious stringop-overflow warning with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91707
--- Comment #12 from Martin Sebor ---
Here's a slightly simplified test case for GCC 12:
$ cat z.c && gcc -O2 -S -Wall -fsanitize=undefined z.c
extern void f (unsigned n, long[n], const long[n]);
void g (unsigned n, const long a[n])
{
long b[n + 1];
f (n, b + 1, a);
long c[n + 1];
(void)c;
}
z.c: In function ‘g’:
z.c:6:4: warning: ‘f’ accessing 34359738360 bytes in a region of size 0
[-Wstringop-overflow=]
6 |f (n, b + 1, a);
|^~~
z.c:6:4: note: referencing argument 2 of type ‘long int[]’
z.c:6:4: note: referencing argument 3 of type ‘const long int[]’
z.c:1:13: note: in a call to function ‘f’
1 | extern void f (unsigned n, long[n], const long[n]);
| ^
[Bug sanitizer/91707] [10/11/12 Regression] spurious stringop-overflow warning with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91707
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2021-01-21 00:00:00 |2021-12-15
Known to fail|11.0|11.2.0, 12.0
--- Comment #11 from Martin Sebor ---
GCC 11 still issues the same -Wstringop-overflow as GCC 10 plus another one for
the call to md_copy_dims():
In function ‘real_from_complex_dims’,
inlined from ‘md_test’ at pr91707.c:14:4:
pr91707.c:7:13: warning: writing 8 bytes into a region of size 0
[-Wstringop-overflow=]
7 |odims[0] = 2;
|~^~~
pr91707.c: In function ‘md_test’:
pr91707.c:13:9: note: destination object ‘dimsR.8’ of size 0
13 |long dimsR[D + 1];
| ^
In function ‘real_from_complex_dims’,
inlined from ‘md_test’ at pr91707.c:14:4:
pr91707.c:8:4: warning: ‘md_copy_dims’ accessing 34359738360 bytes in a region
of size 0 [-Wstringop-overflow=]
8 |md_copy_dims(D, odims + 1, idims);
|^
pr91707.c: In function ‘md_test’:
pr91707.c:8:4: note: referencing argument 2 of type ‘long int *’
pr91707.c:2:13: note: in a call to function ‘md_copy_dims’
2 | extern void md_copy_dims(unsigned int D, long odims[D], const long
idims[D]);
| ^~~~
The second warning is for the md_copy_dims() call in the following IL:
[count: 0]:
md_copy_dims (4294967295, &MEM [(void
*)&dimsR.8 + 8B], idims_13(D));
__builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data1, 0);
[local count: 1073741824]:
dimsR.8 ={v} {CLOBBER};
return;
The first warning is gone in GCC 12 and only the second one remains. It's
triggered by the same md_copy_dims() call with the first argument in excess of
the size of the arrays passed to the function:
[count: 0]:
_29 = dimsR.1_23 + 8;
md_copy_dims (4294967295, _29, idims_13(D));
__builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data1, 0);
[Bug tree-optimization/40635] [12 Regression] bogus name and location in 'may be used uninitialized' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635 Martin Sebor changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #18 from Martin Sebor --- The location is still present at g:45f4e2b01b82c72b3a11ff4ad184d7edcf0e63d4 but is lost after: commit 9f55df63154a39d67ef5b24def7044bf87300831 Author: Andrew Pinski Date: Tue Jun 1 01:05:09 2021 + Replace conditional_replacement with match and simplify This is the first of series of patches to simplify phi-opt to use match and simplify in many cases. This simplification will more things to optimize.
[Bug tree-optimization/40635] [12 Regression] bogus name and location in 'may be used uninitialized' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635 Martin Sebor changed: What|Removed |Added Summary|bogus name and location in |[12 Regression] bogus name |'may be used uninitialized' |and location in 'may be |warning |used uninitialized' warning --- Comment #17 from Martin Sebor --- In GCC 11 the statement in the phipopt2 dump does have a location so this part is a GCC 12 regression: [local count: 5226752]: [local count: 1073741824]: # _16 = PHI <[../pr40635.c:22:20] -1(3), [../pr40635.c:30:12] s42_20(7), [../pr40635.c:29:16] -1(8)> [../pr40635.c:38:5] foo (); [../pr40635.c:39:8] _28 = _16 < 0; [../pr40635.c:39:8] _5 = (int) _28; [../pr40635.c:39:8] _4 = -_5; return _4;
[Bug tree-optimization/40635] bogus name and location in 'may be used uninitialized' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635 --- Comment #16 from Martin Sebor --- With the patch in comment #13 committed in g:9695e1c23be5b5c55d572ced152897313ddb96ae GCC 12 prints the following for the test case in comment #0: pr40635.c: In function ‘server_init’: pr40635.c:14:9: warning: ‘s42’ may be used uninitialized in this function [-Wmaybe-uninitialized] 14 | int s42, x; | ^~~ But it doesn't show where the uninitialized variable is used. GCC 11 only points to the variable's use but doesn't say which variable it is: pr40635.c: In function ‘server_init’: pr40635.c:39:8: warning: ‘s42’ may be used uninitialized in this function [-Wmaybe-uninitialized] 39 | if (sockt_rd < 0) |^ So things have gotten both better and worse. The reason why the GCC 12 warning doesn't point to the use is because the use statement (_28 = _16 < 0; in basic block 8 below) has no location: [local count: 1073741824]: # _16 = PHI <[pr40635.c:22:20] -1(12), s42_9(7), [pr40635.c:29:16] -1(14), s42_18(D)(11), s42_9(13)> [pr40635.c:38:5] foo (); _28 = _16 < 0; _5 = (int) _28; _4 = -_5; return _4; The location can still be found in the mergephi3 dump (pr40635.c.120t.mergephi3) and is gone from the phiopt2 dump (pr40635.c.121t.phiopt2): [local count: 5226752]: [local count: 1073741824]: # _16 = PHI <[../pr40635.c:22:20] -1(3), [../pr40635.c:30:12] s42_20(7), [../pr40635.c:29:16] -1(8)> [../pr40635.c:38:5] foo (); [../pr40635.c:39:8] if (_16 < 0) goto ; [0.73%] else goto ; [99.27%] [local count: 7838309]: [local count: 1073741824]: # _1 = PHI <[../pr40635.c:40:16] -1(10), [../pr40635.c:41:12] 0(9)> return _1; }
[Bug libstdc++/54924] Warn for std::string constructor with wrong size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54924 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Martin Sebor --- GCC 11 and 12 finally diagnose this problem even without -Wsystem-headers, albeit inconsistently. At -O1 GCC 11 issues -Wstringop-overread: In file included from /build/gcc-11-branch/x86_64-pc-linux-gnu/libstdc++-v3/include/string:40, from pr54924.C:2: In static member function ‘static std::char_traits::char_type* std::char_traits::copy(std::char_traits::char_type*, const char_type*, std::size_t)’, inlined from ‘static void std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_S_copy(_CharT*, const _CharT*, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’ at /build/gcc-11-branch/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:359:21, inlined from ‘static void std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_S_copy_chars(_CharT*, const _CharT*, const _CharT*) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’ at /build/gcc-11-branch/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:406:16, inlined from ‘void std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_M_construct(_InIterator, _InIterator, std::forward_iterator_tag) [with _FwdIterator = const char*; _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’ at /build/gcc-11-branch/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:225:25, inlined from ‘void std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_M_construct_aux(_InIterator, _InIterator, std::__false_type) [with _InIterator = const char*; _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’ at /build/gcc-11-branch/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:255:23, inlined from ‘void std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_M_construct(_InIterator, _InIterator) [with _InIterator = const char*; _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’ at /build/gcc-11-branch/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:274:20, inlined from ‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’ at /build/gcc-11-branch/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:521:21, inlined from ‘void __static_initialization_and_destruction_0(int, int)’ at pr54924.C:4:24, inlined from ‘(static initializers for pr54924.C)’ at pr54924.C:4:25: /build/gcc-11-branch/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:409:56: warning: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ reading 5 bytes from a region of size 4 [-Wstringop-overread] 409 | return static_cast(__builtin_memcpy(__s1, __s2, __n)); | ^ As a result of g:b8f2efaed02e8b03d215d74e42d3707761772f64 GCC 12 doesn't issue -Wstringop-overread at any level but at -O2 it does issue -Warray-bounds: In file included from /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/string:53, from pr54924.C:2: In constructor ‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, size_type, const _Alloc&) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’, inlined from ‘void __static_initialization_and_destruction_0(int, int)’ at pr54924.C:4:24, inlined from ‘(static initializers for pr54924.C)’ at pr54924.C:4:25: /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:620:21: warning: array subscript 5 is outside array bounds of ‘const char [4]’ [-Warray-bounds] 620 | _M_construct(__s, __s + __n, std::forward_iterator_tag()); | ^ I'm not happy with how this has turned out but I'm also not sure how to improve things, so I'll resolve this as fixed.
[Bug tree-optimization/90906] diagnose returning pointers to freed memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90906 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #3 from Martin Sebor --- Patch submitted for GCC 12: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583044.html With it, both the trivial C test case and the std::vector test case in comment #0 are diagnosed as expected: pr90906.C:7:20: warning: pointer used after ‘void operator delete(void*, std::size_t)’ [-Wuse-after-free=] 7 | return v.data (); |^ In file included from /build/gcc-63272/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/c++allocator.h:33, from /build/gcc-63272/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/allocator.h:46, from /build/gcc-63272/x86_64-pc-linux-gnu/libstdc++-v3/include/vector:61, from pr90906.C:2: In member function ‘void __gnu_cxx::new_allocator<_Tp>::deallocate(_Tp*, __gnu_cxx::new_allocator<_Tp>::size_type) [with _Tp = int]’, inlined from ‘static void std::allocator_traits >::deallocate(std::allocator_traits >::allocator_type&, std::allocator_traits >::pointer, std::allocator_traits >::size_type) [with _Tp = int]’ at /build/gcc-63272/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/alloc_traits.h:496:23, inlined from ‘void std::_Vector_base<_Tp, _Alloc>::_M_deallocate(std::_Vector_base<_Tp, _Alloc>::pointer, std::size_t) [with _Tp = int; _Alloc = std::allocator]’ at /build/gcc-63272/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:385:19, inlined from ‘void std::_Vector_base<_Tp, _Alloc>::_M_deallocate(std::_Vector_base<_Tp, _Alloc>::pointer, std::size_t) [with _Tp = int; _Alloc = std::allocator]’ at /build/gcc-63272/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:381:7, inlined from ‘std::_Vector_base<_Tp, _Alloc>::~_Vector_base() [with _Tp = int; _Alloc = std::allocator]’ at /build/gcc-63272/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:364:15, inlined from ‘std::vector<_Tp, _Alloc>::~vector() [with _Tp = int; _Alloc = std::allocator]’ at /build/gcc-63272/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:731:7, inlined from ‘int* f()’ at pr90906.C:8:3: /build/gcc-63272/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:157:33: note: call to ‘void operator delete(void*, std::size_t)’ here 157 | _GLIBCXX_OPERATOR_DELETE(_GLIBCXX_SIZED_DEALLOC(__p, __n)); | ^
[Bug tree-optimization/80532] warning on pointer access after free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80532 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #8 from Martin Sebor --- Patch submitted for GCC 12: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583044.html
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 85651, which changed state. Bug 85651 Summary: Invalid -Warray-bounds warning with -O3 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85651 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/85651] Invalid -Warray-bounds warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85651 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Martin Sebor --- Warning suppression by #pragmas works correctly even across inlined calls in GCC 12. I also don't see the warning with recent GCC releases even without the #pragma so both issues seem fixed.
[Bug other/103736] snprintf bogus format-truncation, disregarding modulo on argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103736
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #1 from Martin Sebor ---
The warning is based on the annotated IL below. The duplicate modulo
computation is optimized to take place just once (in PRE), before the
negativity test, the range of the result in the else branch is greater than the
code permits.
void func ()
{
char timezone[4];
signed char timezoneval.0_1;
int _4;
int _12;
signed char _13;
[local count: 1073741824]:
timezoneval.0_1 = timezoneval;
_13 = timezoneval.0_1 % 100;
_12 = (int) _13; >>> _12's range is [-99, 99]
if (timezoneval.0_1 < 0)
goto ; [41.00%]
else
goto ; [59.00%]
[local count: 440234144]:
_4 = -_12; _4's range is [0, 99]
snprintf (&timezone, 4, "-%02d", _4); so no warning here
goto ; [100.00%]
[local count: 633507681]:
snprintf (&timezone, 4, "+%02d", _12); << -Wformat-truncation
[local count: 1073741824]:
timezone ={v} {CLOBBER};
return;
}
The warning can be avoided by using a local temporary copy of the extern
variable, like so
int x = timezoneval;
if(x < 0)
{
snprintf(timezone, sizeof(timezone),"-%02d",-(x % 100));
}
else
{
snprintf(timezone, sizeof(timezone),"+%02d", x % 100);
}
or simply:
int x = timezoneval % 100;
if(x < 0)
{
snprintf(timezone, sizeof(timezone),"-%02d",-x);
}
else
{
snprintf(timezone, sizeof(timezone),"+%02d", x);
}
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 91457, which changed state. Bug 91457 Summary: FAIL: g++.dg/warn/Warray-bounds-4.C -std=gnu++98 (test for warnings, line 25) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/91457] FAIL: g++.dg/warn/Warray-bounds-4.C -std=gnu++98 (test for warnings, line 25)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #20 from Martin Sebor --- g++.dg/warn/Warray-bounds-4.C passes with no FAILs for me with an hppa2.0w-hp-hpux11.11 cross. The test case in comment #2 also triggers the same warning with the cross as with a native x86_64-linux GCC, it looks to me like things are working correctly. If not, please open a new bug.
[Bug middle-end/98166] bogus -Wmismatched-dealloc on user-defined allocator and inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98166 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Sebor --- Fixed in GCC 11.
[Bug tree-optimization/81592] spurious -Wformat-overflow warning with -fsanitize=signed-integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81592 Bug 81592 depends on bug 78969, which changed state. Bug 78969 Summary: bogus snprintf truncation warning due to missing range info https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78969 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/78969] bogus snprintf truncation warning due to missing range info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78969 Martin Sebor changed: What|Removed |Added Known to fail|8.0 |10.3.0, 11.2.0, 8.3.0, ||9.3.0 Target Milestone|--- |12.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #17 from Martin Sebor --- Fixed in GCC 12.
[Bug c++/103703] ICE with -Wmismatched-tags with friends and templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103703 Martin Sebor changed: What|Removed |Added Known to fail||11.2.0, 12.0 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Keywords||patch Status|NEW |ASSIGNED --- Comment #3 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586856.html
[Bug c++/102036] -Wmismatched-tags doesn't warn for explicit instantations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102036
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=103703
--- Comment #3 from Martin Sebor ---
G++ also doesn't warn for more involved cases like the one in pr103703 (with
the ICE fixed):
template
struct A
{
struct B { };
};
template
struct C
{
friend class A::B; // { dg-warning "-Wmismatched-tags" "pr102036" {
xfail *-*-* } }
};
template struct C;
Clang warns for the above but also suffers from a false positive below:
template
struct D
{
friend class A::B; // okay, specialized as class below
};
template <>
struct A
{
class B { };
};
template struct D;
[Bug middle-end/103372] Warning on failure order defaulting to SEQ_CST if not a compile time constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103372 Martin Sebor changed: What|Removed |Added Depends on||99612 CC||msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- The patch for pr99612 submitted last week resolves this problem as well: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99612 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99612 [Bug 99612] Remove "#pragma GCC system_header" from atomic file to warn on incorrect memory order
[Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
--- Comment #13 from Martin Sebor ---
The warning for the test case in comment #12 isn't directly related to ranges:
it's issued simply because the invalid statement is in the IL and not
eliminated by DCE (the secret functions don't let it). Similar warnings have
been issued in equivalent situations for constants propagated through inlining.
Here's one for -Wnonnull (issued since GCC 7):
char *sink;
__attribute__ ((noinline, noipa)) int
null_safe_strlen (const char *p) { return p ?__builtin_strlen (p) : 0; }
static inline void copy (const char *p)
{
int N = null_safe_strlen (p);
if (N) /* disabling this branch prevents the warning */
__builtin_memcpy (sink, p, N);
else
*sink = 0;
}
void f()
{
copy (0); // bogus warning
}
In function ‘copy’,
inlined from ‘f’ at z.c:17:3:
z.c:10:5: warning: argument 2 null where non-null expected [-Wnonnull]
10 | __builtin_memcpy (sink, p, N);
| ^
z.c:10:5: note: in a call to built-in function ‘__builtin_memcpy’
All GCC warnings trigger on invalid statements in the IL, regardless of whether
the statements are in reality reachable. This includes all warnings that
consider data flow like -Wnonnull, -Warray-bounds, and -Wformat-overflow among
many others. Ranges just let them find more invalid statements than constants
alone would. This is also the most basic reason why the -Wstringop- warnings
are issued for the test case in comment #0 or in or PR 103332.
Two changes are behind the spate of recent bug reports about these warnings for
std::string: 1) in GCC 11 we enabled a subset of warnings for code inlined from
system headers, and 2) in GCC 12 thanks to Ranger the range info has become
more accurate and tighter (larger lower bounds and smaller upper bounds).
Before Jonathan suppressed the warnings in r12-5874 in libstdc++, Andrew
MacLeod suggested temporarily (for GCC 12) disabling the context-sensitive
Ranger info and going back to global ranges, until we have a better way of
dealing with the increased accuracy. That would reduce the number of false
positives but it would also correspondingly increase false negatives, and so
defeat one of the main reasons for Ranger: better quality warnings. It might
still be a compromise to consider if the problem turns out to be sufficiently
severe and if we can think of a way of to handle the ranges better in the
future. But with the libstdc++ suppression I'm not convinced the problem is
severe enough anymore. And I also can't think of a solution that would let us
re-enable Ranger for warnings in the future. Nothing I've tried so far has
showed much promise, and neither seems anything anyone has suggested.
Independently, I have been thinking about adding -Wmaybe- forms of some of
these warnings analogous to -Wmaybe-uninitialized (or corresponding levels), to
diagnose conditional problems as in:
char a[4], b[8];
void f (int i)
{
__builtin_memset (i ? a : b, 0, 7); // okay for b, overflow for a: thus
"may overflow a"
}
but I have not been considering disabling the existing warnings (or removing it
from -Wall) and issuing them only under the new option or some new level. That
would in my mind be a drastic step back.
[Bug analyzer/103658] missing -Wanalyzer-use-of-uninitialized-value at -O1 and below for an array access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103658
--- Comment #1 from Martin Sebor ---
Actually, what I was really after is trying to see if the analyzer would print
the conditionals involved in the subscript expressions. But in the simple test
case in comment #0 there are no conditionals. They are here:
int f (int i, int j)
{
int a[3];
a[0] = 1;
a[1] = 2;
if (i < 1 || 3 < i) i = 1;
if (j < 1 || 5 < j) j = 1;
return a[i + j];
}
but it doesn't print them even at -O2 when it does warn:
z.c: In function ‘f’:
z.c:9:11: warning: use of uninitialized value ‘a[]’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
9 | return a[i + j];
| ~^~~
‘f’: event 1
|
|9 | return a[i + j];
| | ~^~~
| | |
| | (1) use of uninitialized value ‘a[]’ here
|
[Bug analyzer/103658] New: missing -Wanalyzer-use-of-uninitialized-value at -O1 and below for an array access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103658
Bug ID: 103658
Summary: missing -Wanalyzer-use-of-uninitialized-value at -O1
and below for an array access
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
I came across this while comparing the middle end -Wuninitialized with
-Wanalyzer-use-of-uninitialized-value. They both trigger at -O2. At -O1, only
-Wuninitialized triggers, even though the IL looks the same between the two
levels (as far as I can tell).
$ cat z.c && gcc -O1 -S -Wall -fdump-tree-uninit=/dev/stdout -fanalyzer z.c
int f (int i, int j)
{
int a[3];
a[0] = 1;
a[1] = 2;
if (i < 1) i = 1;
if (j < 1) j = 1;
return a[i + j];
}
;; Function f (f, funcdef_no=0, decl_uid=1979, cgraph_uid=1, symbol_order=0)
z.c: In function ‘f’:
z.c:9:11: warning: ‘a’ is used uninitialized [-Wuninitialized]
9 | return a[i + j];
| ~^~~
z.c:3:7: note: ‘a’ declared here
3 | int a[3];
| ^
int f (int i, int j)
{
int a[3];
int _1;
int _6;
int _8;
int _9;
[local count: 1073741824]:
_8 = MAX_EXPR ;
_6 = MAX_EXPR ;
_1 = _6 + _8;
_9 = a[_1];
a ={v} {CLOBBER};
return _9;
}
[Bug c++/103534] [12 regression] Spurious -Wstringop-overflow warning with std::string concatencation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103534 --- Comment #8 from Martin Sebor --- We discussed before (e.g., in PR 93971) the idea of annotating std::string with some attribute telling the optimizer the internal pointer doesn't alias with anything except for the this->_M_local_buf or the result of operator new(). Richi seemed open to it but was concerned about correctness. I'm experimenting with two things to improve the context of all these warnings. One is to print the folded condition under which the warning triggers. This would include the conditions involved in all the ranges used to make decisions. I posted the result for this warning here (I'm not sure it's complete, it's just a POC): https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586524.html Another is to print the path through the code (the CFG actually) leading up to the warning site, like the static analyzer does. This will show each GIMPLE_COND after optimization, so it won't correspond exactly to the original source. For libstdc++ code it will show libstdc++ internal conditions that may not be of much use to users. I'll have to see how bad it is to decide if it's a viable approach.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 103215, which changed state. Bug 103215 Summary: [12 regression] gcc generates unexpected warnings on libx11-1.7.2: error: array subscript -2 is outside array bounds of since r12-3124-g820f0940d7ace130 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103215 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/103215] [12 regression] gcc generates unexpected warnings on libx11-1.7.2: error: array subscript -2 is outside array bounds of since r12-3124-g820f0940d7ace130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103215 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Martin Sebor --- Fixed, but not without a price: some false negatives (pr103637).
[Bug middle-end/103637] New: [12 Regression] missing warning writing past the end of one of multiple elements of the same array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103637
Bug ID: 103637
Summary: [12 Regression] missing warning writing past the end
of one of multiple elements of the same array
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The fix for pr103215 is too conservative and causes false negatives for past
the end accesses to array elements like in gcc.dg/warn-strnlen-no-nul.c. A
simple test case that shows the problem is below. The dump shows that both
strcpy calls are plainly out of bounds and both could and should be diagnosed.
$ cat y.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout y.c
extern int x;
extern char b[5][7];
void f (const char *s)
{
__builtin_strncpy (b[3], s, 9); // warning (good)
}
void g (int i, const char *s)
{
char *d = i ? b[3] : b[4];
__builtin_strncpy (d, s, 9); // warning in GCC 11, missing in 12
}
;; Function f (f, funcdef_no=0, decl_uid=1980, cgraph_uid=1, symbol_order=0)
void f (const char * s)
{
[local count: 1073741824]:
__builtin_strncpy (&b[3], s_2(D), 9); [tail call]
return;
}
y.c: In function ‘f’:
y.c:7:3: warning: ‘__builtin_strncpy’ writing 9 bytes into a region of size 7
overflows the destination [-Wstringop-overflow=]
7 | __builtin_strncpy (b[3], s, 9); // warning (good)
| ^~
y.c:3:13: note: at offset 21 into destination object ‘b’ of size 28
3 | extern char b[5][7];
| ^
;; Function g (g, funcdef_no=1, decl_uid=1984, cgraph_uid=2, symbol_order=1)
Removing basic block 3
void g (int i, const char * s)
{
char * iftmp.0_1;
[local count: 1073741824]:
if (i_2(D) != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
[local count: 1073741824]:
# iftmp.0_1 = PHI <&b[3](2), &b[4](3)>
__builtin_strncpy (iftmp.0_1, s_4(D), 9); [tail call]
return;
}
[Bug middle-end/101397] [11 Regression] spurious warning writing to the result of stpcpy minus 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101397 Bug 101397 depends on bug 103143, which changed state. Bug 103143 Summary: [12 Regression] ICE due to infinite recursion in pointer-query.cc https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103143 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/103143] [12 Regression] ICE due to infinite recursion in pointer-query.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103143 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Sebor --- Fixed in r12-5861.
[Bug tree-optimization/103332] [12 Regression] Spurious -Wstringop-overflow on string concatenation in libstdc++ tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103332
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=103534
Summary|Spurious|[12 Regression] Spurious
|-Wstringop-overflow |-Wstringop-overflow on
|warnings in libstdc++ tests |string concatenation in
||libstdc++ tests
Known to fail||12.0
--- Comment #5 from Martin Sebor ---
The first warning is for the invalid memcpy() call below:
struct string D.35215;
...
[local count: 1073312331]:
D.35215._M_string_length = 16;
_62 = D.35215._M_dataplus._M_p;
MEM[(char_type &)_62 + 16] = 0;
D.35222 ={v} {CLOBBER};
MEM[(struct _Alloc_hider *)&D.35222] ={v} {CLOBBER};
MEM[(struct _Alloc_hider *)&D.35222]._M_p = &D.35222.D.28102._M_local_buf;
if (&MEM [(void *)&D.35215 + 16B] == _62)
goto ; [30.00%]
else
goto ; [70.00%]
[local count: 157390518]:
__builtin_memcpy (&D.35222.D.28102._M_local_buf, &MEM [(void
*)&D.35215 + 16B], 17);
goto ; [100.00%]
sizeof std::string::_M_local_buf is 16 but the call writes 17 bytes into it, so
the call is invalid.
I only see the warning at -O1 (and with -D_GLIBCXX_DEBUG). It also goes away
if I force std::string::_M_mutate to be inlined. _M_mutate allocates the
dynamic string so with it inlined GCC can determine that the local buffer is no
longer used and eliminate the invalid call. So as in the other cases we have
seen recently, this false positive is due to some optimizer limitations caused
by the combination of -O1 and a decision to throttle inlining. The second
warning is due to the same issue. It too goes away with more aggressive
inlining (on x86_64 setting -finline-limit=200 avoids it).
[Bug tree-optimization/96658] Unhelpful -Wstrict-overflow warning from std::push_heap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96658
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
CC||msebor at gcc dot gnu.org
Known to fail||10.3.0, 11.2.0, 12.0, 9.3.0
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-12-08
--- Comment #1 from Martin Sebor ---
Confirmed on trunk plus GCC 9, 10, 11 but not 8, so strictly speaking it's a
regression:
pr96658.C: In function ‘void push_heap(T*, T*) [with T = long unsigned int]’:
pr96658.C:19:47: warning: assuming signed overflow does not occur when changing
X +- C1 cmp C2 to X cmp C2 -+ C1 [-Wstrict-overflow]
19 | void f(unsigned long* v) { push_heap(v, v+3); }
| ^
The warning first appeared with r263875.
[Bug middle-end/99612] Remove "#pragma GCC system_header" from atomic file to warn on incorrect memory order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99612 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #4 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586402.html
[Bug tree-optimization/103542] [10/11/12 Regregression] bogus -Warray-bounds while index is limited by switch/case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103542
Martin Sebor changed:
What|Removed |Added
Keywords||missed-optimization
Blocks||56456
CC||msebor at gcc dot gnu.org
--- Comment #2 from Martin Sebor ---
The IL for the function is below. It seems quite inefficient compared to GCC
9.
void get_default_config.part.0 (const uint32_t id)
{
uint32_t error;
uint32_t entry;
unsigned int _4;
uint32_t * _5;
[local count: 118111600]:
goto ; [100.00%]
[local count: 955630225]:
entry_2 = entry_1 + 1;
[local count: 1073741824]:
# entry_1 = PHI
_4 = config[id_3(D)].num_apples;
if (entry_1 < _4)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 118111600]:
config[id_3(D)].num_apples = 0;
_5 = &config[id_3(D)].num_lemons;
switch (id_3(D)) [20.00%], case 0: [20.00%], case 1:
[20.00%], case 2: [20.00%], case 3: [20.00%]>
[local count: 23622320]:
:
MEM [(uint32_t *)&config][0].num_lemons = 0;
goto ; [100.00%]
[local count: 23622320]:
:
MEM [(uint32_t *)&config][1].num_lemons = 0;
goto ; [100.00%]
[local count: 23622320]:
:
MEM [(uint32_t *)&config][2].num_lemons = 0;
goto ; [100.00%]
[local count: 23622320]:
:
MEM [(uint32_t *)&config][3].num_lemons = 0;
goto ; [100.00%]
[local count: 23622320]:
:
MEM [(uint32_t *)&config][id_3(D)].num_lemons = 0;
<<< -Warray-bounds
[local count: 118111602]:
# error_14 = PHI <0(7), 255(10), 0(6), 0(9), 0(8)>
config[id_3(D)].num_lemons = 0;
config[id_3(D)].lemons = 0B;
foo (0);
return;
}
In GCC 9 both the function and the final assembly are much more compact:
et_default_config.part.0 (const uint32_t id)
{
struct fruit_config[4] * _2;
sizetype _13;
sizetype _14;
[local count: 118111601]:
_13 = (sizetype) id_3(D);
_14 = _13 * 16;
_2 = &config + _14;
MEM[(unsigned int *)_2] = 0;
config[id_3(D)].lemons = 0B;
foo (0); [tail call]
return;
}
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug c++/103534] [12 regression] Spurious -Wstringop-overflow warning with std::string concatencation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103534
--- Comment #4 from Martin Sebor ---
Yes, the warning does disappear when malloc() and free() are used instead of
operator new and delete. foo() also ends up much better optimized, even at
-O1:
__attribute__((abi_tag ("cxx11")))
struct string foo ()
{
struct string & _7(D);
char * _69;
[local count: 1073741824]:
_69 = __builtin_malloc (17);
__builtin_memcpy (_69, "1234567890123456", 16);
MEM[(char_type &)_69 + 16] = 0;
MEM[(struct basic_string *)_7(D)]._M_dataplus._M_p = _69;
MEM[(struct basic_string *)_7(D)].D.33183._M_allocated_capacity = 16;
MEM[(struct basic_string *)_7(D)]._M_string_length = 16;
return _7(D);
}
The -O1 dump in comment #1 doesn't look right, I may have messed something up.
The same issue happens at -O2 where the dump is as follows:
=== BB 3
Imports: n_5(D)
Exports: _1 n_5(D)
_1 : n_5(D)(I)
n_5(D) int [-INF, -1][1, +INF]
[local count: 536870913]:
_1 = (sizetype) n_5(D);
if (_1 == 1)
goto ; [51.12%]
else
goto ; [48.88%]
_1 : sizetype [1, 2147483647][18446744071562067968, +INF]
3->4 (T) _1 : sizetype [1, 1]
3->4 (T) n_5(D) : int [1, 1]
3->5 (F) _1 : sizetype [2, 2147483647][18446744071562067968, +INF]
3->5 (F) n_5(D) : int [-INF, -1][2, +INF]
=== BB 4
[local count: 274448412]:
MEM[(char *)&b] = 0;
goto ; [100.00%]
=== BB 5
[local count: 262422500]:
__builtin_memcpy (&b, &a, _1);
[Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
Martin Sebor changed:
What|Removed |Added
Keywords|missed-optimization |
--- Comment #10 from Martin Sebor ---
Using -O2 doesn't avoid the warning in general. The following C test case
reproduces an equivalent warning at all optimization levels (with GCC 11 it
triggers a -Warray-bounds only). The warning works as designed. If you don't
want these warnings to trigger on these cases we need change the design,
starting with outlining the conditions under which they should trigger. As it
is, they all trigger for every invalid call in the IL, whether it's in the
source code of the original test case, or in the standard library headers (like
in the case of std::string) inlined into user code, or whether it's isolated by
the compiler. Fiddling with optimization levels, disabling them for system
headers, or other heuristics won't prevent them under other conditions.
$ cat t.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout
-Wno-array-bounds t.c
static inline __attribute__ ((always_inline))
void f (char *d, const char *s, __SIZE_TYPE__ n)
{
if (n == 1)
*d = *s;
else
__builtin_memcpy (d, s, n);
}
static inline __attribute__ ((always_inline))
void ff (char *d, const char *s0, const char *s1)
{
f (d, s0, s1 - s0);
}
void g (void*);
void h (int n)
{
char a[1] = "";
char b[16];
if (n)
ff (b, a, a + n);
g (b);
}
;; Function h (h, funcdef_no=2, decl_uid=1990, cgraph_uid=3, symbol_order=2)
Removing basic block 7
void h (int n)
{
char b[16];
char a[1];
sizetype _1;
[local count: 1073741824]:
a = "";
if (n_5(D) != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
_1 = (sizetype) n_5(D);
if (_1 == 1)
goto ; [51.12%]
else
goto ; [48.88%]
[local count: 274448412]:
MEM[(char *)&b] = 0;
goto ; [100.00%]
[local count: 262422500]:
__builtin_memcpy (&b, &a, _1);
[local count: 1073741824]:
g (&b);
a ={v} {CLOBBER};
b ={v} {CLOBBER};
return;
}
In function ‘f’,
inlined from ‘ff’ at t.c:13:3,
inlined from ‘h’ at t.c:23:5:
t.c:7:5: warning: ‘__builtin_memcpy’ reading 2 or more bytes from a region of
size 1 [-Wstringop-overread]
7 | __builtin_memcpy (d, s, n);
| ^~
t.c: In function ‘h’:
t.c:20:8: note: source object ‘a’ of size 1
20 | char a[1] = "";
|^
[Bug tree-optimization/96188] -Wstringop-overflow false positive on std::vector::push_back with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96188 Martin Sebor changed: What|Removed |Added Known to work||12.0 --- Comment #9 from Martin Sebor --- Today's trunk doesn't reproduce it but the warning is still issued with GCC 12 for a GCC 11 translation unit, so it must be some library change that's made it go away.
[Bug tree-optimization/100366] spurious warning - std::vector::clear followed by std::vector::insert(vec.end(), ...) with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366 Martin Sebor changed: What|Removed |Added Known to fail||11.2.0, 12.0 Last reconfirmed|2021-05-02 00:00:00 |2021-12-2 --- Comment #10 from Martin Sebor --- Unchanged in GCC 12.
[Bug c++/103534] [12 regression] Spurious -Wstringop-overflow warning with std::string concatencation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103534 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Last reconfirmed||2021-12-02 Ever confirmed|0 |1 Blocks||88443 CC||msebor at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Martin Sebor --- The warning is for the memcpy() call in BB 12 with _73 being in the reported excessive range: [local count: 172868773]: _209 = D.41961._M_dataplus._M_p; _103 = _69 + 16; __builtin_memcpy (_103, _209, _73); <<< 27->12 (T) _73 : long unsigned int [18446744073709551600, +INF] The range comes from BB 27: === BB 27 Imports: _73 Exports: _73 _73 long unsigned int [0, 0][18446744073709551600, +INF] __size_74 const long unsigned int [0, 16] [local count: 523844769]: if (_73 != 0) goto ; [33.00%] else goto ; [67.00%] 27->12 (T) _73 : long unsigned int [18446744073709551600, +INF] 27->12 (T) __size_74 : const long unsigned int [0, 15] 27->13 (F) _73 : long unsigned int [0, 0] 27->13 (F) __size_74 : const long unsigned int [16, 16] The magic 16 most likely has to do with the small internal std::string buffer that's 16 bytes big. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 103483, which changed state. Bug 103483 Summary: context-sensitive ranges change triggers stringop-overread https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX
[Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483 Martin Sebor changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #4 from Martin Sebor --- I don't think this can be "fixed." Most middle end warnings work a single statement at a time and depend on optimization like constant propagation and dead code elimination to do their job. If one optimization exposes an invalid statement that would otherwise be eliminated by another optimization that doesn't take place, the warnings trigger. That's all by design and there's no way change that. In the test case in comment #0 where the precondition is that d be less than a, making it explicit (e.g., either as Andrew suggests in comment #1 or by adding an equivalen assert statement) seems like the best and only solution.
[Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483 Martin Sebor changed: What|Removed |Added Component|c++ |middle-end Keywords||missed-optimization CC||msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- The warning is only issued at -O1. It's based on the statement in the IL and the values or ranges of its arguments. In this case the IL and the argument values are below: === BB 6 Imports: _1 d_6(D) Exports: _1 d_6(D) _1 sizetype [0, 0][2, 15] [local count: 362271902]: if (_1 == 0) goto ; [100.00%] else goto ; [0.00%] 6->8 (T) _1 : sizetype [0, 0] 6->7 (F) _1 : sizetype [2, 15] >>> _1 > 1 === BB 7 [local count: 346397698]: # _2 = PHI <&s.D.26133._M_local_buf(6), _19(3)> __builtin_memcpy (_2, &buffer, _1); <<< -Wstringop-overread The memcpy() call reads between 2 and 15 bytes from the one-byte buffer. So the warning code is working as designed. The problem is that at -O1 the code isn't optimized sufficiently to discover that the memcpy call only reads 1 byte (the function call isn't inlined and so the constant argument isn't propagated into the call). GCC 11 doesn't warn because it's unable to determine the range of the last memcpy() argument. Thanks to the Ranger improvements GCC 12 is able to do better. In some cases this should improve the S/N ratio of the middle end diagnostics that depend on ranges. Unfortunately, in others like this one where other optimizations are disabled it can make things worse.
[Bug testsuite/103469] [12 regression] c-c++-common/attr-retain-9.c fails after r12-5483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103469 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Last reconfirmed||2021-11-29 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Martin Sebor --- Fixed.
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 88232, which changed state. Bug 88232 Summary: Please implement -Winfinite-recursion https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88232 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/88232] Please implement -Winfinite-recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88232 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |12.0 --- Comment #6 from Martin Sebor --- Done for GCC 12.
[Bug c/103360] [meta-bug] bogus/missing -Waddress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103360 Bug 103360 depends on bug 96507, which changed state. Bug 96507 Summary: missing -Waddress for member references https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96507 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/96507] missing -Waddress for member references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96507 Martin Sebor changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Martin Sebor --- Fixed in GCC 12.
[Bug c/79074] -Waddress difference between C and C++ with (T*)0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79074
Martin Sebor changed:
What|Removed |Added
Known to fail||10.2.0, 11.2.0, 12.0,
||7.3.0, 8.3.0, 9.2.0
Last reconfirmed|2017-01-12 00:00:00 |2021-11-23
--- Comment #3 from Martin Sebor ---
No change in GCC 12. The inequality test below is still not diagnosed in C
(but is in C++):
int g (int i) { return &i != (int *) 0; }
[Bug c++/96507] missing -Waddress for member references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96507 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED Keywords||patch --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585178.html
[Bug tree-optimization/103215] [12 regression] gcc generates unexpected warnings on libx11-1.7.2: error: array subscript -2 is outside array bounds of since r12-3124-g820f0940d7ace130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103215 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #7 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585180.html
[Bug fortran/103369] New: [12 Regression] gfortran.dg/vector_subscript_1.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103369 Bug ID: 103369 Summary: [12 Regression] gfortran.dg/vector_subscript_1.f90 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- I see the following unexpected failures with today's build of GCC 12: FAIL: gfortran.dg/vector_subscript_1.f90 -O1 execution test FAIL: gfortran.dg/vector_subscript_1.f90 -O2 execution test FAIL: gfortran.dg/vector_subscript_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/vector_subscript_1.f90 -O3 -g execution test FAIL: gfortran.dg/vector_subscript_1.f90 -Os execution test The output just before each failure looks like this: Execution timeout is: 300 spawn [open ...] STOP 12 FAIL: gfortran.dg/vector_subscript_1.f90 -O1 execution test I didn't investigate beyond that so I don't know if the problem is in the front end or elsewhere. The test hasn't changed since February 2018 so I'm guessing it's not the cause of the problem.
[Bug c++/103363] confusing -Wnonnull-compare testing a reference argument for equality to null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103363 Martin Sebor changed: What|Removed |Added Known to fail||10.3.0, 11.2.0, 12.0, ||6.5.0, 7.5.0, 8.5.0, 9.3.0 Keywords||diagnostic --- Comment #1 from Martin Sebor --- Both warnings started to be issued in GCC 6.
[Bug c++/103363] New: confusing -Wnonnull-compare testing a reference argument for equality to null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103363
Bug ID: 103363
Summary: confusing -Wnonnull-compare testing a reference
argument for equality to null
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Since the conversion of the address of a reference to bool is diagnosed by
-Waddress, issuing a second warning for it isn't necessary. Mentioning
attribute nonnull where there is one in the source code seems confusing.
$ cat t.C && gcc -O2 -S -Wall t.C
struct S { int i; };
bool f (const S &s)
{
return &s;
}
t.C: In function ‘bool f(const S&)’:
t.C:5:10: warning: the compiler can assume that the address of ‘s’ will never
be NULL [-Waddress]
5 | return &s;
| ^~
t.C:3:18: note: ‘s’ declared here
3 | bool f (const S &s)
| ~^
t.C:5:11: warning: ‘nonnull’ argument ‘s’ compared to NULL [-Wnonnull-compare]
5 | return &s;
| ^
Clang issues just one warning (though the wording doesn't seem ideal either:
there's no evidence of dereferencing a null pointer so assuming that's what
necessarily led the programmer to the test doesn't seem warranted):
warning: reference cannot be bound to dereferenced null pointer in well-defined
C++ code; pointer may be assumed to always convert to true
[-Wundefined-bool-conversion]
return &s;
[Bug c++/96507] missing -Waddress for member references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96507
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Summary|Feature request: improve|missing -Waddress for
|"-Waddress" (or equivalent) |member references
|for function references |
|inside structs |
CC||msebor at gcc dot gnu.org
Last reconfirmed||2021-11-22
--- Comment #1 from Martin Sebor ---
Confirmed with GCC 12. Since the warning is issued for non-member references
(the first case below) but not for members (the second case) I would consider
this a bug rather than an enhancement request.
$ cat pr96507.C && gcc -S -Wall pr96507.C
typedef void F ();
extern F &fr;
extern int &ir;
bool gfun ()
{
return &fr != 0; // -Waddress (expected)
}
bool gvar ()
{
return &ir != 0; // -Waddress (expected)
}
struct S
{
F &fr;
int &ir;
};
extern S s;
bool hfun ()
{
return &s.fr != 0; // missing warning
}
bool hvar ()
{
return &s.ir != 0; // missing warning
}
pr96507.C: In function ‘bool gfun()’:
pr96507.C:8:14: warning: the compiler can assume that the address of ‘fr’ will
never be NULL [-Waddress]
8 | return &fr != 0; // -Waddress (expected)
| ^~~~
pr96507.C:3:11: note: ‘fr’ declared here
3 | extern F &fr;
| ^~
pr96507.C: In function ‘bool gvar()’:
pr96507.C:13:14: warning: the compiler can assume that the address of ‘ir’ will
never be NULL [-Waddress]
13 | return &ir != 0; // -Waddress (expected)
| ^~~~
pr96507.C:4:13: note: ‘ir’ declared here
4 | extern int &ir;
| ^~
[Bug c/103343] Invalid codegen when comparing pointer to one past the end and then dereferencing that pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103343 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- (In reply to Gabriel Ravier from comment #0) > PS: This also results in plenty of invalid warnings when compiling with > -Wall: > > : In function 'f': > :6:9: warning: array subscript 1 is outside array bounds of 'int[1]' > [-Warray-bounds] > 6 | *p = 2; > | ^~ > :1:12: note: at offset 4 into object 'x' of size 4 > 1 | extern int x[1], y; > |^ The warning in this case is valid and helpful: it's undefined to attempt to access an object using a pointer derived from a pointer to an unrelated object (the equality between pointers to adjacent objects notwithstanding).
[Bug c/103360] [meta-bug] bogus/missing -Waddress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103360 Martin Sebor changed: What|Removed |Added Last reconfirmed||2021-11-22 Keywords||diagnostic, meta-bug Ever confirmed|0 |1 Alias||Waddress Status|UNCONFIRMED |NEW
[Bug c/103360] New: [meta-bug] bogus/missing -Waddress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103360 Bug ID: 103360 Summary: [meta-bug] bogus/missing -Waddress Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- This is a meta-bug to track false positives and negatives in the -Waddress warning first introduced in GCC 4.2 (in r122136).
[Bug c/78989] Missing -Waddress warning due to -Wno-system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78989
--- Comment #9 from Martin Sebor ---
GCC 12 (and prior, down to 10) warns for the test case:
$ cat pr78989.ii && gcc -S -Wall pr78989.ii
int
asan_poison_variables ()
{
return (asan_poison_variables &&
# 6 "gimplify.cpp" 3 4
__null
);
}
pr78989.ii: In function ‘int asan_poison_variables()’:
pr78989.ii:4:10: warning: the address of ‘int asan_poison_variables()’ will
never be NULL [-Waddress]
4 | return (asan_poison_variables &&
| ^
pr78989.ii:2:1: note: ‘int asan_poison_variables()’ declared here
2 | asan_poison_variables ()
| ^
[Bug c/102867] [12 Regression] -Waddress from macro expansion in readelf.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Sebor --- Fixed.
[Bug c++/33925] [10/11 Regression] gcc -Waddress lost some useful warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33925 Martin Sebor changed: What|Removed |Added Known to work||12.0 Summary|[10/11/12 Regression] gcc |[10/11 Regression] gcc |-Waddress lost some useful |-Waddress lost some useful |warnings|warnings Known to fail|12.0|10.2.0 --- Comment #11 from Martin Sebor --- Fixed in GCC 12.
[Bug c/103334] New: missing -Wc++-compat for a function redeclared with different qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103334 Bug ID: 103334 Summary: missing -Wc++-compat for a function redeclared with different qualifiers Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- Redeclaring a function that differs only in the qualifiers on the return type is rejected by G++ in all C++ modes but not diagnosed by GCC in C mode. The warbing should be enhanced to diagnose that as well (-Wignored-qualifiers is enabled by -Wextra but not -Wall). $ cat z.c && gcc -O2 -S -Wall -Wextra -Wc++-compat z.c const int f (void); volatile int f (void); z.c:1:1: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] 1 | const int f (void); | ^ z.c:2:1: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] 2 | volatile int f (void); | ^~~~ Compilation error for the same code with G++: $ g++ -O2 -S -Wall -Wextra -std=c++98 -xc++ z.c z.c:1:1: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] 1 | const int f (void); | ^ z.c:2:1: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] 2 | volatile int f (void); | ^~~~ z.c:2:14: error: ambiguating new declaration of ‘volatile int f()’ 2 | volatile int f (void); | ^ z.c:1:11: note: old declaration ‘const int f()’ 1 | const int f (void); | ^
[Bug tree-optimization/103332] Spurious -Wstringop-overflow warnings in libstdc++ tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103332 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102958 --- Comment #1 from Martin Sebor --- Suspect at least some of these might be due to the same underlying problem as pr102958. I suppressed a subset of these warnings in g:sy9a27acc30a34b7854db32eac562306cebac6fa1e.
[Bug c/103310] null comparison with a weak symbol eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103310
Martin Sebor changed:
What|Removed |Added
Component|middle-end |c
--- Comment #1 from Martin Sebor ---
The test case below shows that storing the address of the alias in a local
pointer avoids the problem. The dumps show that the problem is in the front
end which folds the test of the address of the weak symbol to true.
$ cat pr103310.c && gcc -Wall -O2 -S -fdump-tree-original=/dev/stdout
-fdump-tree-optimized=/dev/stdout pr103310.c
extern void alias (void);
void call_alias (void)
{
__builtin_printf ("in %s: alias = %p\n", __func__, alias);
if (alias)
alias ();
}
void call_ptr_alias (void)
{
void (*p)(void) = alias;
__builtin_printf ("in %s: alias = %p\n", __func__, p);
if (p)
p ();
}
extern void alias (void) __attribute__((weak));
pr103310.c: In function ‘call_alias’:
pr103310.c:7:7: warning: the address of ‘alias’ will always evaluate as ‘true’
[-Waddress]
7 | if (alias)
| ^
;; Function call_alias (null)
;; enabled by -tree-original
{
static const char __func__[11] = "call_alias";
static const char __func__[11] = "call_alias";
__builtin_printf ((const char *) "in %s: alias = %p\n", (const char *)
&__func__, alias);
if (1)
{
alias ();
}
}
;; Function call_ptr_alias (null)
;; enabled by -tree-original
{
void (*) (void) p = alias;
static const char __func__[15] = "call_ptr_alias";
static const char __func__[15] = "call_ptr_alias";
void (*) (void) p = alias;
__builtin_printf ((const char *) "in %s: alias = %p\n", (const char *)
&__func__, p);
if (p != 0B)
{
p ();
}
}
;; Function call_alias (call_alias, funcdef_no=0, decl_uid=1945, cgraph_uid=1,
symbol_order=0)
void call_alias ()
{
static const char __func__[11] = "call_alias";
[local count: 1073741824]:
__builtin_printf ("in %s: alias = %p\n", &__func__, alias);
alias (); [tail call]
return;
}
;; Function call_ptr_alias (call_ptr_alias, funcdef_no=1, decl_uid=1949,
cgraph_uid=2, symbol_order=1)
Removing basic block 5
void call_ptr_alias ()
{
static const char __func__[15] = "call_ptr_alias";
[local count: 1073741824]:
__builtin_printf ("in %s: alias = %p\n", &__func__, alias);
if (alias != 0B)
goto ; [53.47%]
else
goto ; [46.53%]
[local count: 574129753]:
alias (); [tail call]
[local count: 1073741824]:
return;
}
[Bug middle-end/98503] [11/12 regression] -Warray-bounds false positive with global variables at -O2 since r11-3306-g3f9a497d1b0dd9da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98503 Martin Sebor changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #16 from Martin Sebor --- *** Bug 103292 has been marked as a duplicate of this bug. ***
[Bug middle-end/103292] [12 regression] xorg-server-1.20.13 -Werror=array-bounds false positive on unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103292
Martin Sebor changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
Component|c |middle-end
Blocks||56456
CC||jeffreyalaw at gmail dot com
--- Comment #3 from Martin Sebor ---
The originally intended purpose of this instance of -Warray-bounds was to warn
for accesses to smaller buffers by larger lvalues, like in this function:
struct A { int i; };
struct B { long j; };
struct B* make_B_from_A (const struct A *p)
{
struct B *q = __builtin_malloc (sizeof *p); // should be sizeof *q
q->j = p->i;
return q;
}
Here a warning should be issued regardless of whether -fstrict-aliasing is in
effect because the access is out of bounds. That the warning also triggers in
instances when the problem isn't one of an out-of-bounds access but rather an
aliasing violation was incidental (i.e., I didn't set out with that as a goal),
but because -Wstrict-aliasing in GCC is very limited, seemed like a bonus.
So an argument could be (and in pr98503 in fact was) made that the instances of
-Warray-bounds where the ultimate access is strictly in bounds should be
replaced by one of -Wstrict-aliasing, which is enabled only when
-fstrict-aliasing is in effect. I agreed and submitted a patch to do that:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564483.html
Regrettably, the change was rejected. I CC the reviewer for his comments.
*** This bug has been marked as a duplicate of bug 98503 ***
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug tree-optimization/102759] [12 Regression] ICE: Segmentation fault in maybe_check_access_sizes since r12-2976-gb48d4e6818674898
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102759 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Sebor --- Fixed.
[Bug middle-end/103310] New: null comparison with a weak symbol eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103310
Bug ID: 103310
Summary: null comparison with a weak symbol eliminated
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The following test case was prompted by the discussion in the review of a
-Waddress enhancement:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584749.html
Before folding the test in call_alias() to true, GCC issues a -Waddress. At
runtime the program then crashes. In the review Jason suggests GCC should
reject the subsequent declaration of the alias with an error because it has
been used (and because the test for null may have been eliminated).
cat a.c && gcc -DUSE_ALIAS -O2 -Wall -c a.c && gcc -O2 -Wall a.c a.o && ./a.out
#if USE_ALIAS
extern void alias (void);
void call_alias (void)
{
__builtin_printf ("in %s: alias = %p\n", __func__, alias);
if (alias)
alias ();
}
extern void alias (void) __attribute__((weak));
#else
extern void alias (void) __attribute__((weak)); // not defined
extern void call_alias (void);
int main (void)
{
__builtin_printf ("in %s: alias = %p\n", __func__, alias);
call_alias ();
}
#endif
a.c: In function ‘call_alias’:
a.c:9:7: warning: the address of ‘alias’ will always evaluate as ‘true’
[-Waddress]
9 | if (alias)
| ^
in main: alias = (nil)
in call_alias: alias = (nil)
Segmentation fault (core dumped)
[Bug c/101702] [12 Regression] ICE: in handle_argspec_attribute, at c-family/c-attribs.c:3623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101702 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Sebor --- Fixed.
[Bug c/103292] [12 regression] xorg-server-1.20.13 -Werror=array-bounds false positive on unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103292
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
Keywords||diagnostic
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=102151
CC||msebor at gcc dot gnu.org
--- Comment #1 from Martin Sebor ---
The warning is intended. The program allocates an object of a size that's
smaller than the size of the type used to access it:
pPicture->pSourcePict = (union _SourcePict*) malloc(sizeof(struct
_PictSolidFill));
pPicture->pSourcePict->type = 0;
It's not valid to access an object of one type using an lvalue of another. In
simple cases GCC diagnoses violations of this requirement by -Wstrict-aliasing.
-Warray-bounds doesn't detect aliasing violations but it does detect a subset
of the problem that's apparent when the size of the lvalue's type is greater
than the size of the object. The object must be big enough for the whole
lvalue, even if the accessed member is within the bounds of the smaller object.
The following is a smaller test case that should make the issue clearer. See
also pr102151 for a similar report.
$ cat a.c && gcc -O2 -S -Wall a.c
struct A { char a[1]; };
struct B { char a[2]; };
union U { struct A a; struct B b; };
void* f (void)
{
union U *p = __builtin_malloc (sizeof (struct A));
p->a.a[0] = 0;
return p;
}
a.c: In function ‘f’:
a.c:8:4: warning: array subscript ‘union U[0]’ is partly outside array bounds
of ‘unsigned char[1]’ [-Warray-bounds]
8 | p->a.a[0] = 0;
|^~
a.c:7:16: note: object of size 1 allocated by ‘__builtin_malloc’
7 | union U *p = __builtin_malloc (sizeof (struct A));
|^~~~
[Bug c/101702] [12 Regression] ICE: in handle_argspec_attribute, at c-family/c-attribs.c:3623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101702 --- Comment #5 from Martin Sebor --- (In reply to Jakub Jelinek from comment #4) > Martin clearly prefers some other fix, so I'll let him fix it himself. I think I just misread your change. It doesn't cause the problem I was concerned about. I've submitted a slightly enhanced version that avoids additional problems here: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584658.html
[Bug tree-optimization/102960] [10/11 Regression] ICE: in sign_mask, at wide-int.h:855 in GCC 10.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102960 Martin Sebor changed: What|Removed |Added Known to fail|12.0| Known to work||12.0 Summary|[10/11/12 Regression] ICE: |[10/11 Regression] ICE: in |in sign_mask, at|sign_mask, at |wide-int.h:855 in GCC |wide-int.h:855 in GCC |10.3.0 |10.3.0 --- Comment #5 from Martin Sebor --- Fixed in GCC 12.0. Will backport.
[Bug tree-optimization/103223] [12 regression] Access attribute dropped when ipa-sra is applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103223 --- Comment #9 from Martin Sebor --- Outside of code comments only the user-visible attribute access interface is documented in the manual. The main difference is probably that attribute access can be added by the user for any pair of arguments (without a limit on the number of arguments). Another difference is that the implicit attribute access captures the VLA argument bounds and the [static N] specifier that tells us that array must have at least N elements (this latter part could be used for optimization). The attribute access mode none means that the argument isn't dereferenced but must point to an object of the specified size (I'm guessing that's not quite the same as the 'x' character in fn spec). For the common subset it might make sense to transform attribute access to fnspec when it applies to the first N arguments (with N being the fnspec limit). Come to think of it, an alternate approach to solving the IPA problem with lost attribute access might be to extend attr fnspec to encode the same things as it and for the warnings to use fnspec instead. The same caveat applies that not all of what attribute access describes can be used for optimization, so the API would have to make the distinction quite clear.
[Bug tree-optimization/103176] -foptimize-strlen causes stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103176 --- Comment #7 from Martin Sebor --- You're welcome and no need to apologize. We want to improve the warnings (and the rest of the compiler) and these reports help us understand both the limitations and opportunities for improvements, or at least get a better sense of where the pain points for users are. The challenge with warning offering any type of suggestions is that unless they are pretty much guaranteed to help they could do more harm then good in the cases when they don't. This makes such suggestions pretty much limited to simple flow-insensitive warnings (those issued by language front ends).
[Bug tree-optimization/102759] [12 Regression] ICE: Segmentation fault in maybe_check_access_sizes since r12-2976-gb48d4e6818674898
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102759 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #4 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584516.html
[Bug tree-optimization/103223] [12 regression] Access attribute dropped when ipa-sra is applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103223
--- Comment #7 from Martin Sebor ---
For an attribute access that's explicitly specified on the declaration of a
function I think these steps should work:
1) Call init_attr_rdwr_indices() to initialize the mapping for the original
function with type fntype:
rdwr_map rdwr_idx;
init_attr_rdwr_indices (&rdwr_idx, TYPE_ATTRIBUTES (fntype));
2) Iterate over the mapping, rdwr_idx, creating an attribute access for each
pair of function arguments coupled by the attribute (i.e., pointer and size)
that also appears in the cloned function, and dropping those that don't.
Append each specification to a chain of attributes.
3) Call decl_attributes() on the chain.
So maybe an API like this:
bool copy_attr_access (tree newdecl, tree decl_to_clone, bitmap
args_to_copy);
where newdecl is the function cloned from the original decl_to_clone but with
fewer arguments and args_to_copy is a bitmap of the positions of the
decl_to_clone arguments for which to copy the access spec? (Or, alternatively,
args_to_drop.) Would this work for what you're thinking of using it for?
This approach won't work for an explicitly specified attribute access where IPA
substitutes a constant for the bound, as in:
__attribute__ ((access (write_only, 1, 2))) void f (int *a, int n) { ... }
when transformed into with 7 being the value of n:
void f.constprop.7 (int *a) { ... }
Ideally, we want to change the cloned function to this:
void f.constprop.7 (int a[7]) { ... }
so that calls it with fewer than 7 elements are diagnosed. But there's no way
to specify __attribute__ ((access)) like that. That's done internally, in
stages, by the front end by adding an "arg spec" attribute to the argument a as
it's seen in the argument list. Once the argument list is fully processed the
front end then creates the attribute access specification for the function from
the "arg spec" attributes on all the arguments. We need a way to do the same
thing in the middle end.
if he above is close, can you show me where you would call the function from?
[Bug tree-optimization/103215] [12 regression] gcc generates unexpected warnings on libx11-1.7.2: error: array subscript -2 is outside array bounds of since r12-3124-g820f0940d7ace130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103215 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug tree-optimization/103215] [12 regression] gcc generates unexpected warnings on libx11-1.7.2: error: array subscript -2 is outside array bounds of since r12-3124-g820f0940d7ace130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103215
Martin Sebor changed:
What|Removed |Added
Blocks||56456
--- Comment #6 from Martin Sebor ---
The warning follows the type_3 pointer to determine the object it points to.
That leads it to either name_and_type or name_and_type + OFFSET where OFFSET is
in [1, 254]. Between those two, it conservatively picks the former because it
has more space (this is done to avoid false positives for stores). What it
neglects to do is adjust the bounds of the offset to reflect that of the other.
So the code ends up determining that type_43 points to name_and_type with a
zero offset when it should instead arrive at name_and_type with an offset in
[0, 254]. (If the code also considered the ASSERT_EXPR conditions it should
end up with an offset in [1, 254].)
[local count: 1073741824]:
extract (&name_and_type);
type_7 = __builtin_strrchr (&name_and_type, 95);
if (type_7 != 0B)
goto ; [70.00%]
else
goto ; [30.00%]
[local count: 751619281]:
type_9 = type_7 + 1;
[local count: 1073741824]:
# type_3 = PHI
_1 = __builtin_strcmp ("hot", type_3);
if (_1 == 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
type_10 = type_3 + 18446744073709551615;
if (&name_and_type == type_3)
goto ; [17.43%]
else
goto ; [82.57%]
[local count: 443294313]:
type_11 = &MEM [(void *)type_3 + -2B];
if (&name_and_type == type_10)
goto ; [17.43%]
else
goto ; [82.57%]
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug c/101702] [12 Regression] ICE: in handle_argspec_attribute, at c-family/c-attribs.c:3623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101702 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug tree-optimization/102009] [12 Regression] ICE: in gimple_call_arg, at gimple.h:3272 by r12-2976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102009 --- Comment #3 from Martin Sebor --- gimple_builtin_call_types_compatible_p() returns false even for calls with trivial mismatches like an int where a size_t is expected. I would prefer a less restrictive test that doesn't prevent detecting these bugs in such calls to function without a prototype.
[Bug tree-optimization/103223] [12 regression] Access attribute dropped when ipa-sra is applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103223 --- Comment #5 from Martin Sebor --- (In reply to Martin Jambor from comment #4) > (In reply to Jan Hubicka from comment #0) ... > > Martin, I wonder if if you would be OK with simply dropping the access when > > function signature changes (which I can prepare patch for) or do you want to > > dive into updating it? > > I would be OK with it but I don't think people who invested the energy > into these new security warnings would. I replied earlier on gcc-patches: I've always intended the access attribute to eventually benefit optimization so please feel free (and encouraged :) to use it for that purpose. The idea behind it was not just to catch bugs but also to enable optimizations based on the expectation that those bugs will have been fixed. (This has to be done carefully since the attribute is also implicitly added in contexts where relying on it wouldn't correct for optimization; the attirbute API makes it possible to distinguish these cases.) By dropping the attribute in IPA passes we would not only give up on detecting the bugs the IPA transformations expose but also on the optimization opportunities they might open up.
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 103176, which changed state. Bug 103176 Summary: -foptimize-strlen causes stringop-overflow warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103176 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX
[Bug tree-optimization/103176] -foptimize-strlen causes stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103176
Martin Sebor changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--- |WONTFIX
--- Comment #4 from Martin Sebor ---
Thanks for the test case. The warning is based on the IL below. In basic
block 16 the result of operator new is assigned to _134, and in basic block 19
the code stores zero at an negative offset from _134. So the warning is doing
its job here: the invalid statement exists in the emitted program, it just may
be unreachable and GCC can't prove that.
[local count: 19040066]:
_82 = len_49 - lastpos.2_4;
length_83 = (int) _82;
o ={v} {CLOBBER};
_134 = operator new (1); >>> _134
goto ; [100.00%]
...
[local count: 19040066]:
MEM[(char *)_134] = 0;
_85 = length_83 + 1;
_86 = (unsigned int) _85;
if (_86 == 0)
goto ; [80.71%]
else
goto ; [19.29%]
[local count: 25513689]:
MEM[(char *)_134 + -1B] = 0; <<< -Wstringop-overflow
goto ; [100.00%]
The cause of the warning is in the subString() function where it can't prove
that the length argument won't become negative:
string subString(unsigned begin, int length) const
{
// if start after string
// or no proper substring length
if ((length <= 0) || (begin>=size()))
return string{ "" };
// clamp length to maximal value
if ((length+begin) > size())
length = size()-begin; <<< length not proven to
become -1
string o;
o.reserve(length+1);
for (int i=0; i
[Bug middle-end/97048] [meta-bug] bogus/missing -Wstringop-overread warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048 Bug 97048 depends on bug 98465, which changed state. Bug 98465 Summary: Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/98465] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 Martin Sebor changed: What|Removed |Added Known to fail|11.0| Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #33 from Martin Sebor --- With the workaround in r11-7146 the warning should no longer be issued for std::string::insert. Thanks to r12-2087 suppression by #pragma GCC diagnostic works reliably even with inlining in GCC 12, so the warning can also be suppressed using it. I'm not working on any other improvements related to the underlying problem but I think this report can be resolved as fixed in GCC 11 and 12.
