[Bug c++/93810] missing -Wmismatched-tags and -Wredundant-tags on a typedef of an implicit class template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93810 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Martin Sebor --- Fixed.
[Bug middle-end/101600] [12 Regression] Spurious -Warray-bounds downcasting a polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101600 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #3 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577985.html
[Bug tree-optimization/101977] [12 Regression] array subscript 0 is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101977 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577985.html
[Bug tree-optimization/102006] A false warning "Array subscript -N is outside array bounds warning"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102006
Martin Sebor changed:
What|Removed |Added
Blocks||56456
CC||msebor at gcc dot gnu.org
Keywords||diagnostic
Component|c++ |tree-optimization
--- Comment #5 from Martin Sebor ---
I ca confirm the warning but not yet that it's a bug or limitation in GCC.
The IL does show an access via an out-of-bounds pointer to a local object:
(struct Element *)&holder + -32B, so it's working as designed. I can't tell if
the access itself, adjusted for the offset of the member, is valid (i.e.,
what's D.146911's offset within holder), but even if it is, the warning
validates pointers without considering subsequent adjustments so if something
earlier ends up emitting one that's out-of-bounds the warning will trigger.
The out-of-bounds offset first shows up in the fixup_cfg3 dump. ListHolder is
multiply derived from the same base class whose members freely cast the this
pointer to the derived class so maybe that somehow results in the intermediate
negative offset. The translation unit is almost 90,000 of twisty C++ code so
it will take a bit of time to reduce to something manageable.
void List_TestFunc (const struct TestContext & context)
{
...
struct ListHolder holder;
...
[local count: 1073741824]:
_15 = MEM[(struct base_single_link *)&holder].pNext;
if (_15 != 0B)
goto ; [85.10%]
else
goto ; [14.90%]
[local count: 913754293]:
iftmp.2_16 = &MEM[(struct Element *)_15 + -32B].D.146911;
[local count: 1073741821]:
# i$m_p_24 = PHI
goto ; [100.00%]
...
[local count: 9761289345]:
# i$m_p_21 = PHI
if (&MEM[(struct Element *)&holder + -32B].D.146911 != i$m_p_21) <<<
-Warray-bounds
goto ; [89.00%]
else
goto ; [11.00%]
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug tree-optimization/101977] [12 Regression] array subscript 0 is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101977 Martin Sebor changed: What|Removed |Added Target Milestone|--- |12.0 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug tree-optimization/101977] array subscript 0 is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101977
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2021-08-19
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Martin Sebor ---
Stepping through the GCC code it looks like the same problem as in pr101600.
The warning doesn't reset the base0 flag when processing a PHI node involving
null pointers and those that don't point to known objects. Here's a simple C
test case. The one in pr101600 is C++ so I'll keep this open just to remember
to add both.
$ cat z.c && gcc -O2 -S -Wall -fdump-tree-vrp1=/dev/stdout z.c
struct A { int i; };
struct B { struct A a1; struct A a2; };
void f (struct A *p, int i)
{
struct A *q = i < 0 ? 0 : 0 < i ? p : 0;
struct B *r = (struct B*)((char *)q - __builtin_offsetof (struct B, a2));
r->a1.i = 0;
}
;; Function f (f, funcdef_no=0, decl_uid=1949, cgraph_uid=1, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4 6
;; 2 succs { 3 6 }
;; 3 succs { 6 4 }
;; 4 succs { 6 }
;; 6 succs { 1 }
SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j
i_6 -> { i_2(D) }
Incremental SSA update started at block: 2
Number of blocks in CFG: 7
Number of blocks to update: 2 ( 29%)
Value ranges after VRP:
iftmp.0_1: struct A * VARYING
i_2(D): int VARYING
p_3(D): struct A * VARYING
i_6: int [0, +INF] EQUIVALENCES: { i_2(D) } (1 elements)
z.c: In function ‘f’:
z.c:8:4: warning: array subscript 0 is outside array bounds of ‘struct
A[2305843009213693951]’ [-Warray-bounds]
8 | r->a1.i = 0;
|^~
z.c:4:19: note: at offset -4 into object ‘p’ of size [0, 9223372036854775807]
4 | void f (struct A *p, int i)
| ~~^
void f (struct A * p, int i)
{
struct A * iftmp.0_1;
[local count: 1073741824]:
if (i_2(D) >= 0)
goto ; [59.00%]
else
goto ; [41.00%]
[local count: 633507681]:
if (i_2(D) != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 316753840]:
[local count: 1073741824]:
# iftmp.0_1 = PHI <0B(4), 0B(2), p_3(D)(3)> <<< p_3(D)(3) is an function
argument
MEM[(struct B *)iftmp.0_1 + -4B].a1.i = 0; <<< -Warray-bounds
return;
}
As an aside, the usual practice is to include a test case or a translation unit
when reporting a bug. I reproduced the warning myself by building Binutils so
I don't need the details we normally ask for, but it would be nice to at least
mention what you believe is wrong, if only as a courtesy, and how you convinced
yourself of it.
[Bug other/101984] [12 Regression] gimple-ssa-warn-access memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101984 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Martin Sebor --- The leak should be plugged now.
[Bug other/101984] [12 Regression] gimple-ssa-warn-access memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101984
Martin Sebor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #2 from Martin Sebor ---
Patch I'm testing:
diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
index f3efe564af0..4a2dd9ade77 100644
--- a/gcc/gimple-ssa-warn-access.cc
+++ b/gcc/gimple-ssa-warn-access.cc
@@ -3310,12 +3310,16 @@ pass_waccess::check (basic_block bb)
unsigned
pass_waccess::execute (function *fun)
{
+ /* Create a new ranger instance and associate it with FUN. */
m_ranger = enable_ranger (fun);
basic_block bb;
FOR_EACH_BB_FN (bb, fun)
check (bb);
+ /* Release the ranger instance and replace it with a global ranger. */
+ disable_ranger (fun);
+
return 0;
}
[Bug c/101953] bug on the default cast operator from double to unsigned short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #23 from Martin Sebor --- With a constant argument it should be possible to issue a warning at compile time. If that's sufficient I would suggest to open a new bug requesting it. Similarly, if the sanitizers should detect it but don't please open a separate request to make that work. Link them to this one for background.
[Bug tree-optimization/101854] [11 Regression] Invalid warning -Wstringop-overflow wrong argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101854
Martin Sebor changed:
What|Removed |Added
Summary|[11/12 Regression] Invalid |[11 Regression] Invalid
|warning -Wstringop-overflow |warning -Wstringop-overflow
|wrong argument |wrong argument
Known to fail||11.2.0
--- Comment #9 from Martin Sebor ---
Fixed for GCC 12. The patch is far too intrusive to backport but the following
should fix the problem in GCC 11:
diff --git a/gcc/calls.c b/gcc/calls.c
index fcb0d6dec69..f116923c890 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -2295,14 +2295,15 @@ initialize_argument_information (int num_actuals
ATTRIBUTE_UNUSED,
operand for later processing. */
if (attr_access *access = rdwr_idx.get (argpos))
{
+ int idx = i - !!struct_value_addr_value;
if (POINTER_TYPE_P (type))
{
- access->ptr = args[i].tree_value;
+ access->ptr = args[idx].tree_value;
// A nonnull ACCESS->SIZE contains VLA bounds. */
}
else
{
- access->size = args[i].tree_value;
+ access->size = args[idx].tree_value;
gcc_assert (access->ptr == NULL_TREE);
}
}
[Bug jit/101942] many jit test failures (test-accessing-bitfield.c.exe et al.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101942 Martin Sebor changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Martin Sebor --- Never mind. It was caused by an uninitialized variable introduced by a change in my tree and for some reason only caught by the JIT tests and none others. Sorry about that!
[Bug c++/101940] Implement -fignored-attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101940 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Last reconfirmed||2021-08-17 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #3 from Martin Sebor --- If the only thing the new option is meant to control is -Wattributes warnings I tend to agree that adding an optional argument to -Wattributes= would be a natural enhancement. (Similar to -Wnormalized= or -Wsuggest-attribute= except with a free-form string as an argument). I would expect the existing diagnostic pragmas to work with it too: #pragma GCC ignored "-Wattributes=vendor::attr1"
[Bug jit/101942] New: many jit test failures (test-accessing-bitfield.c.exe et al.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101942
Bug ID: 101942
Summary: many jit test failures (test-accessing-bitfield.c.exe
et al.)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
A regression test run with today's top of trunk shows failures in the following
JIT tests:
! FAIL: jit.dg/test-compile-to-assembler.c, (1: +1)
! FAIL: jit.dg/test-compile-to-object.c, (1: +1)
! FAIL: output-of-test-compile-to-assembler.c.s (1: +1)
! FAIL: output-of-test-compile-to-dynamic-library.c.so (1: +1)
! FAIL: output-of-test-compile-to-executable.c.exe (2: +2)
! FAIL: output-of-test-compile-to-object.c.o (1: +1)
! FAIL: test-accessing-bitfield.c.exe (1: +1)
! FAIL: test-accessing-struct.c.exe (1: +1)
! FAIL: test-accessing-union.c.exe (1: +1)
! FAIL: test-alignment.cc.exe (1: +1)
! FAIL: test-alignment.c.exe (1: +1)
! FAIL: test-arith-overflow.c.exe (1: +1)
! FAIL: test-array-as-pointer.c.exe (1: +1)
! FAIL: test-arrays.c.exe (1: +1)
! FAIL: test-asm.cc.exe (1: +1)
! FAIL: test-asm.c.exe (1: +1)
! FAIL: test-autovectorize.c.exe (1: +1)
! FAIL: test-benchmark.c.exe (1: +1)
! FAIL: test-builtin-memcpy.c.exe (1: +1)
! FAIL: test-builtin-unreachable.c.exe (1: +1)
! FAIL: test-calling-external-function.c.exe (1: +1)
! FAIL: test-calling-function-ptr.c.exe (1: +1)
! FAIL: test-cast.c.exe (1: +1)
! FAIL: test-combination.c.exe (1: +1)
! FAIL: test-compile-to-assembler.c.exe (1: +1)
! FAIL: test-compile-to-dynamic-library.c.exe (1: +1)
! FAIL: test-compile-to-executable.c.exe (1: +1)
! FAIL: test-compile-to-object.c.exe (1: +1)
! FAIL: test-compound-assignment.c.exe (1: +1)
! FAIL: test-constants.c.exe (1: +1)
! FAIL: test-debug-strings.c.exe (1: +1)
! FAIL: test-dot-product.c.exe (1: +1)
! FAIL: test-empty.c.exe (1: +1)
! FAIL: test-error-array-bounds.c.exe (1: +1)
! FAIL: test-error-gcc_jit_context_new_bitfield-invalid-width.c.exe (1: +1)
! FAIL: test-error-gcc_jit_lvalue_get_address-bitfield.c.exe (1: +1)
! FAIL: test-error-gcc_jit_timer_pop-mismatch.c.exe (1: +1)
! FAIL: test-error-gcc_jit_timer_pop-too-many.c.exe (1: +1)
! FAIL: test-error-impossible-must-tail-call.c.exe (1: +1)
! FAIL: test-error-pr63969-missing-driver.c.exe (1: +1)
! FAIL: test-error-unrecognized-dump.c.exe (1: +1)
! FAIL: test-expressions.c.exe (1: +1)
! FAIL: test-factorial-must-tail-call.c.exe (1: +1)
! FAIL: test-fibonacci.c.exe (1: +1)
! FAIL: test-functions.c.exe (1: +1)
! FAIL: test-global-set-initializer.c.exe (1: +1)
! FAIL: test-linked-list.c.exe (1: +1)
! FAIL: test-long-names.c.exe (1: +1)
! FAIL: test-long-string-literal.c.exe (1: +1)
! FAIL: test-nested-contexts.c.exe (1: +1)
! FAIL: test-nested-loops.c.exe (1: +1)
! FAIL: test-operator-overloading.cc.exe (1: +1)
! FAIL: test-pr66700-observing-write-through-ptr.c.exe (1: +1)
! FAIL: test-pr66779.c.exe (1: +1)
! FAIL: test-pr95306-builtin-types.c.exe (1: +1)
! FAIL: test-pr95314-rvalue-reuse.c.exe (1: +1)
! FAIL: test-quadratic.cc.exe (1: +1)
! FAIL: test-quadratic.c.exe (1: +1)
! FAIL: test-returning-function-ptr.c.exe (1: +1)
! FAIL: test-string-literal.c.exe (1: +1)
! FAIL: test-sum-of-squares.c.exe (1: +1)
! FAIL: test-switch.cc.exe (1: +1)
! FAIL: test-switch.c.exe (1: +1)
! FAIL: test-threads.c.exe (1: +1)
! FAIL: test-trap.c.exe (1: +1)
! FAIL: test-types.c.exe (1: +1)
! FAIL: test-using-global.c.exe (1: +1)
! FAIL: test-validly-unreachable-block.c.exe (1: +1)
! FAIL: test-vector-rvalues.cc.exe (1: +1)
! FAIL: test-vector-types.cc.exe (1: +1)
! FAIL: test-version.c.exe (1: +1)
! FAIL: test-volatile.c.exe (1: +1)
! FAIL: verify-dynamic-library.c.exe (1: +1)
Most fail with a SEGV:
FAIL: test-accessing-bitfield.c.exe killed: 29762 exp6 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
[Bug tree-optimization/101831] Spurious maybe-uninitialized warning on std::array::size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101831
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2021-08-16
--- Comment #1 from Martin Sebor ---
-Wmaybe-uninitialized is also issued when an uninitialized object is passed by
reference to a const-qualified argument. This includes passing the address of
an such object to the implicit this pointer in calls to member functions. This
form of the warning runs very early on and before any function calls have been
inlined, so it can't tell that the function doesn't actually read from the
uninitialized object. The same effect can be reproduced in C in a call to a
non-member function (see below). It's possible to run the early uninitialized
pass later but probably not without introducing some false negatives. I'm not
sure that the std::array use case is common enough to justify the potential
for the false negatives (or conversely, that the potential is significant
enough not to avoid the false positives). So confirmed. It requires some
thought and testing.
$ cat a.c && gcc -S -Wall -Wextra a.c
inline __attribute__ ((always_inline))
int f (const int *p) { (void)&p; return 0; }
int g (void)
{
int i;
return f (&i);
}
a.c: In function ‘g’:
a.c:7:10: warning: ‘i’ may be used uninitialized [-Wmaybe-uninitialized]
7 | return f (&i);
| ^~
a.c:2:5: note: by argument 1 of type ‘const int *’ to ‘f’ declared here
2 | int f (const int *p) { (void)&p; return 0; }
| ^
a.c:6:7: note: ‘i’ declared here
6 | int i;
| ^
[Bug tree-optimization/101912] -Wmaybe-uninitialized false alarm in tzdb localtime.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
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
Status|UNCONFIRMED |NEW
CC||msebor at gcc dot gnu.org
Last reconfirmed||2021-08-16
--- Comment #1 from Martin Sebor ---
Confirmed, not a regression. The warning pass considers only one condition: n
> 0. It doesn't consider the conjunction of that condition with those implied
by not using the other unintialized PHI operand and that the use is unreachable
otherwise (i.e., that !(corr == 1 && leapcnt != 0 && prevcorr - 1 > 1 && n !=
leapcnt) cannot be true at the point of the use). The logic seem too
complicated to me to figure it out but I could be missing something.
int tzloadbody ()
{
int corr;
int leapcnt;
int prevcorr;
int n;
_Bool _1;
_Bool _2;
_Bool _5;
unsigned int _6;
int _8;
unsigned int _9;
_Bool _21;
_Bool _27;
[local count: 95397018]:
# .MEM_12 = VDEF <.MEM_11(D)>
n_13 = getint ();
if (n_13 > 0)
goto ; [96.34%] >>> if n > 0...
else
goto ; [3.66%]
[local count: 91905487]: <<<
...prevcorr_14(D)(7) uninitialized here
[local count: 1034442874]: <<< if n > 0 && !(corr
== 1 && leapcnt != 0 && prevcorr - 1 > 1 && n != leapcnt)
# prevcorr_18 = PHI<<<
# leapcnt_23 = PHI
# .MEM_20 = PHI <.MEM_15(8), .MEM_12(7)>
# .MEM_15 = VDEF <.MEM_20>
corr_16 = getint ();
if (corr_16 <= 0)
goto ; [3.66%]
else
goto ; [96.34%]
[local count: 996582264]:
_1 = corr_16 == 1;
_2 = leapcnt_23 != 0;
_9 = (unsigned int) prevcorr_18; <<<
-Wmaybe-uninitialized
_6 = _9 + 4294967295;
_5 = _6 > 1;
_21 = _1 & _2;
_27 = _5 & _21;
if (_27 != 0)
goto ; [21.78%]
else
goto ; [78.22%] >>> corr == 1 &&
leapcnt != 0 && prevcorr - 1 > 1
[local count: 217055616]:
goto ; [100.00%]
[local count: 978344809]:
leapcnt_17 = leapcnt_23 + 1;
if (n_13 != leapcnt_17)
goto ; [96.34%] >>> corr == 1 &&
leapcnt != 0 && prevcorr - 1 > 1 && n != leapcnt
else
goto ; [3.66%]
[local count: 35807421]:
goto ; [100.00%]
[local count: 942537388]:
goto ; [100.00%]>>> corr == 1 &&
leapcnt != 0 && prevcorr - 1 > 1 && n != leapcnt
[local count: 3491531]:
[local count: 95397019]:
# _8 = PHI <0(9), n_13(12), -1(11), -1(10)>
# .MEM_10 = PHI <.MEM_12(9), .MEM_15(12), .MEM_15(11), .MEM_15(10)>
# VUSE <.MEM_10>
return _8;
}
[Bug middle-end/100406] bogus/missing -Wmismatched-new-delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100406 Bug 100406 depends on bug 101791, which changed state. Bug 101791 Summary: missing warning on a mismatch between scalar and array forms of new and delete https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101791 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/101791] missing warning on a mismatch between scalar and array forms of new and delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101791 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Martin Sebor --- Fixed in r12-2908.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 101734, which changed state. Bug 101734 Summary: missing warning reading from a write-only object https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101734 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/101734] missing warning reading from a write-only object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101734 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Sebor --- Done for GCC 12.
[Bug c++/51545] missing -Wparentheses diagnostic with compound assignment used as condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51545 Martin Sebor changed: What|Removed |Added Known to fail||11.2.0, 12.0, 4.1.0 Last reconfirmed|2017-08-18 00:00:00 |2021-8-13 Version|unknown |4.0.0 --- Comment #5 from Martin Sebor --- No change in 12.0.
[Bug c++/101833] [9/10/11/12 Regression] ICE with -Wformat on a constructor with a virtual base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101833 Martin Sebor changed: What|Removed |Added Known to fail||10.3.0, 11.2.0, 12.0 --- Comment #2 from Martin Sebor --- The warning is issued when the declaration is seen (either with -Wall or with just -Wattributes). The ICE is a side-effect of -Wformat checking calls to the function.
[Bug tree-optimization/101854] [11/12 Regression] Invalid warning -Wstringop-overflow wrong argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101854 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/101854] [11/12 Regression] Invalid warning -Wstringop-overflow wrong argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101854
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Last reconfirmed||2021-08-12
Blocks||88443
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #7 from Martin Sebor ---
Below is a further simplified test case. The code in
initialize_argument_information() that computes the sizes of actual arguments
to array parameters and issues a warning if the former is less than expected
doesn't consider the implicit pointer argument passed to functions that return
structs by value. It's off by one for those.
$ cat t.c && gcc -S -Wall t.c
struct A { int a[5]; };
struct A g (int*, int[6][8]);
struct A f (void)
{
int a[2];
return g (a, 0);
}
t.c: In function ‘f’:
t.c:8:10: warning: ‘g’ accessing 192 bytes in a region of size 8
[-Wstringop-overflow=]
8 | return g (a, 0);
| ^~~~
t.c:8:10: note: referencing argument 2 of type ‘int (*)[8]’
t.c:3:10: note: in a call to function ‘g’
3 | struct A g (int*, int[6][8]);
| ^
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug middle-end/88781] [meta-bug] bogus/missing -Wstringop-truncation warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 Bug 88781 depends on bug 101451, which changed state. Bug 101451 Summary: Incorrect -Wstringop-truncation warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101451 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug tree-optimization/101451] Incorrect -Wstringop-truncation warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101451 Martin Sebor changed: What|Removed |Added Resolution|--- |INVALID CC||msebor at gcc dot gnu.org Status|WAITING |RESOLVED Blocks||88781 --- Comment #4 from Martin Sebor --- The warning is by design. For strncat() which always appends a nul it's documented to trigger if the call truncates the source string. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 [Bug 88781] [meta-bug] bogus/missing -Wstringop-truncation warnings
[Bug middle-end/101829] problems with inline + __attribute__ ((malloc (deallocator)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101829 Martin Sebor changed: What|Removed |Added Blocks||99715 Keywords||diagnostic See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100861 --- Comment #3 from Martin Sebor --- Agreed that the inlining restriction is a problem. See also bug 100861 comment #2 (the problem is even more severe in C++ because operators new and delete are treated as if they had the attribute even if they don't). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99715 [Bug 99715] [meta-bug] bogus/missing Wmismatched-dealloc warnings
[Bug tree-optimization/101830] [12 Regression] Incorrect error messages beginning with r12-2591 (backward jump threader)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830
Martin Sebor changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #12 from Martin Sebor ---
No problem.
By the way, it looks to me like safe_inc_pos() also isn't entirely safe since
testing the result of the postincrement lets pos reach 1024 on function return.
It should either use preincrement or 1023 as the bound.
It's of course possible to issue a more nuanced warning ("may be out of
bounds") for expressions that are invalid only under some condition, in basic
blocks that aren't dominated by function entry. It has been suggested (and
considered) a number of times before. The problem with a simplistic solution
like that is that it would result in the vast majority of warnings being
phrased this way, because most are in such blocks. The only certain warnings
would be either in trivial functions or in the initial basic blocks. I'm
working on introducing this distinction for PHIs but I don't have any ideas
what to do for problems like this one.
[Bug tree-optimization/101830] [12 Regression] Incorrect error messages beginning with r12-2591 (backward jump threader)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830 --- Comment #8 from Martin Sebor --- Created attachment 51298 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51298&action=edit Change to test case that avoids -Warray-bounds. The attached change to test case avoids all -Warray-bounds instances.
[Bug tree-optimization/101830] [12 Regression] Incorrect error messages beginning with r12-2591 (backward jump threader)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830 --- Comment #6 from Martin Sebor --- I've only looked at the first warning so far. It's issued for the access in bb 8: [local count: 4057510040]: pos.80_31 = pos; if (pos.80_31 <= 1023) goto ; [96.34%] else goto ; [3.66%] [local count: 256307115]: # pos.80_21 = PHI _1 = linebuf[pos.80_21]; <<< -Warray-bounds ... The index is in the range [1024, INT_MAX] so the warning is correct given the IL. There isn't much I see that could be improved about the diagnostic except mentioning the range of the subscript rather than just its lower bound. This instance of the warning or its phrasing also haven't changed in years. It's not the result of a recent enhancement or a questionable heuristic but simply reflects a change in the IL, and it's always been phrased as "is out of bounds". No "may be out of bounds" form exists, never has, and adding one wouldn't help in this instance. That said, since pos is a global variable, the test in safe_inc_pos() that would otherwise constrain its value only has that effect in the absence of intervening statements that might overwrite it. You might get a better result with a pair of "setter" and "getter" functions where the latter asserted the range via __builtin_unreachable() before returning the variable. Otherwise, the test is what likely is used by the backward threader to introduce the unreachable branch which isn't eliminated because GCC can't prove the variable isn't incremented beyond its upper limit. (Aldy is in a much better position to explain this.)
[Bug tree-optimization/101793] Incorrect -Wmaybe-uninitialized on an unreachable use at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #6 from Martin Sebor --- Let me see if I can handle this.
[Bug tree-optimization/101793] Incorrect production of ‘may be used uninitialized in this function [-Werror=maybe-uninitialized]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #5 from Martin Sebor --- (In reply to Andrew Pinski from comment #2) > I don't know enough about the uninit predicated code to understand why it > can't find that bb15 is predicated on p_9(D) != 0 The pass sees that saved_10(D)(15) is uninitialized in bb 8 where the PHI with it as an operand is used and it's missing logic to figure out that the predicate guarding the uninitialized operand's definition is impossible to satisfy (i.e., that bb 15 is unreachable). The condition is p == 0 && v == 0 && fn () != 0 && p != 0 but the pass doesn't even compute it.
[Bug middle-end/96989] SSA_NAMEs in Wuninitialized warning messages after r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96989 --- Comment #6 from Martin Sebor --- The tree pretty-printer would do better by obviating the internal differences: e.g., it could convert the IL for h(): a = __builtin_malloc (_1); _2 = a + 8; _3 = *_2; directly to a[2].
[Bug middle-end/96989] SSA_NAMEs in Wuninitialized warning messages after r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96989
Martin Sebor changed:
What|Removed |Added
Assignee|ibuclaw at gdcproject dot org |unassigned at gcc dot
gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Component|d |middle-end
Last reconfirmed||2021-08-06
--- Comment #5 from Martin Sebor ---
Confirmed. The format depends on the IL which is less than ideal since that
exposes internal differences that users don't care about and that can be
confusing.
$ cat pr96989.c && gcc -S -Wall pr96989.c
int f (void)
{
unsigned a[3];
return a[2];
}
int g (unsigned n)
{
int a[n];
return a[2];
}
int h (unsigned n)
{
unsigned *a = __builtin_malloc (n);
return a[2];
}
pr96989.c: In function ‘f’:
pr96989.c:4:11: warning: ‘a’ is used uninitialized [-Wuninitialized]
4 | return a[2];
| ~^~~
pr96989.c:3:12: note: ‘a’ declared here
3 | unsigned a[3];
|^
pr96989.c: In function ‘g’:
pr96989.c:10:11: warning: ‘*a[2]’ is used uninitialized [-Wuninitialized]
10 | return a[2];
| ~^~~
pr96989.c: In function ‘h’:
pr96989.c:16:11: warning: ‘*a_7 + 8’ is used uninitialized [-Wuninitialized]
16 | return a[2];
| ~^~~
[Bug middle-end/101799] Warning messages for PMF leak internal names like ::__pfn and ::__delta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101799 --- Comment #2 from Martin Sebor --- PR 96989 is related only in that it also involves the pretty printer. Otherwise, to avoid SSA_NAMEs the pretty-printer needs to recursively expand them into their assignments from DECLs or expressions (e.g., results of function calls etc.)
[Bug middle-end/101799] Warning messages for PMF leak internal names like ::__pfn and ::__delta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101799
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Blocks||24639
Component|c++ |middle-end
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Keywords||diagnostic
Last reconfirmed||2021-08-06
--- Comment #1 from Martin Sebor ---
The internal names are the ++ front end representation of member pointers as
seen in the dump below. The pretty printer might be able to do a better job
formatting them (i.e., recognize it's a member pointer and print the name as it
appears in the source) but then we'd end up with a duplicate warning. To avoid
that -Wuninitialized would also have to recognize member pointers and treat
them as special. It might help to mark the internal names DECL_ARTIFICIAL.
bool f ()
{
struct
{
void S:: (struct S *) * __pfn;
long int __delta;
} mp;
...
void S:: (struct S *) * _1;
...
:
# VUSE <.MEM_4(D)>
_1 = mp.__pfn; <<< -Wuninitialized
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug middle-end/101791] missing warning on a mismatch between scalar and array forms of new and delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101791 Martin Sebor changed: What|Removed |Added Target Milestone|--- |12.0 Blocks||100406 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Version|12.0|11.2.1 Last reconfirmed||2021-08-05 Keywords||diagnostic Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100406 [Bug 100406] bogus/missing -Wmismatched-new-delete
[Bug middle-end/101791] New: missing warning on a mismatch between scalar and array forms of new and delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101791
Bug ID: 101791
Summary: missing warning on a mismatch between scalar and array
forms of new and delete
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 -Wmismatched-new-delete warning introduced in GCC 11 is meant to diagnose
calls to operator delete with pointers obtained from a mismatched form or
overload of operator new. A poster child for such a mismatch is the scalar
form of a delete expression with an argument obtained from array new. GCC 11
diagnoses such mismatches when they involve member operators new and delete (as
in g() below) but it fails to do the same for the default non-member operators
(as in h()).
$ cat t.C && gcc -S -Wall t.Ctypedef __SIZE_TYPE__ size_t;
struct A
{
void* operator new (size_t);
void operator delete (void*);
void* operator new[] (size_t);
void operator delete[] (void*);
};
void f (void*);
void g ()
{
A *p = new A[7];
f (p);
delete p;// -Wmismatched-new-delete (good)
}
void h ()
{
int *p = new int[7];
f (p);
delete p;// missing warning
}
t.C: In function ‘void g()’:
t.C:18:10: warning: ‘static void A::operator delete(void*)’ called on pointer
returned from a mismatched allocation function [-Wmismatched-new-delete]
18 | delete p;// -Wmismatched-new-delete (good)
| ^
t.C:16:17: note: returned from ‘static void* A::operator new [](size_t)’
16 | A *p = new A[7];
| ^
[Bug tree-optimization/101770] -Wmaybe-uninitialized false alarm with only locals in GNU diffutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101770
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
CC||msebor at gcc dot gnu.org
--- Comment #2 from Martin Sebor ---
Here's output from the uninitialized pass patched to show in more detail what's
going on. Cycles can contribute to false positives. The chain length greater
messages also show possible reasons for false positives in an unpatched GCC
(the patched pass raises the limits to avoid them). The note after the warning
shows the condition under which GCC determines the uninitialized variable is
used (it needs improvement).
Examining phi: cmd1_68 = PHI
cycle detected
cycle detected
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
cycle detected
predicate::predicate (def_bb = 6, use_bb = 3, func_t) initialized from 9
dep_chains:
24 -> 8, 8 -> 9, 9 -> 26, 14 -> 15, 15 -> 32
24 -> 8, 8 -> 9, 9 -> 26, 14 -> 15, 15 -> 18
24 -> 8, 8 -> 9, 9 -> 26, 14 -> 15, 15 -> 19
24 -> 8, 8 -> 10, 10 -> 11, 11 -> 27, 14 -> 15, 15 -> 32
24 -> 8, 8 -> 10, 10 -> 11, 11 -> 27, 14 -> 15, 15 -> 18
24 -> 8, 8 -> 10, 10 -> 11, 11 -> 27, 14 -> 15, 15 -> 19
24 -> 8, 8 -> 10, 10 -> 13, 13 -> 30, 14 -> 15, 15 -> 32
24 -> 8, 8 -> 10, 10 -> 13, 13 -> 30, 14 -> 15, 15 -> 18
24 -> 8, 8 -> 10, 10 -> 13, 13 -> 30, 14 -> 15, 15 -> 19
init_from_control_deps { { 24 -> 8, 8 -> 9, 9 -> 26, 14 -> 15, 15 -> 32 }, { 24
-> 8, 8 -> 9, 9 -> 26, 14 -> 15, 15 -> 18 }, { 24 -> 8, 8 -> 9, 9 -> 26, 14 ->
15, 15 -> 19 }, { 24 -> 8, 8 -> 10, 10 -> 11, 11 -> 27, 14 -> 15, 15 -> 32 }, {
24 -> 8, 8 -> 10, 10 -> 11, 11 -> 27, 14 -> 15, 15 -> 18 }, { 24 -> 8, 8 -> 10,
10 -> 11, 11 -> 27, 14 -> 15, 15 -> 19 }, { 24 -> 8, 8 -> 10, 10 -> 13, 13 ->
30, 14 -> 15, 15 -> 32 }, { 24 -> 8, 8 -> 10, 10 -> 13, 13 -> 30, 14 -> 15, 15
-> 18 }, { 24 -> 8, 8 -> 10, 10 -> 13, 13 -> 30, 14 -> 15, 15 -> 19 } }:
(empty)
Found unguarded use in bb 3: cmd1_12 = PHI
cycle detected
cycle detected
cycle detected
cycle detected
cycle detected
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
cycle detected
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
cycle detected
cycle detected
predicate::predicate (def_bb = 6, use_bb = 20, func_t) initialized from 3
dep_chains:
24 -> 8, 8 -> 9, 9 -> 26, 14 -> 15, 15 -> 20
24 -> 8, 8 -> 10, 10 -> 11, 11 -> 27, 14 -> 15, 15 -> 20
24 -> 8, 8 -> 10, 10 -> 13, 13 -> 30, 14 -> 15, 15 -> 20
init_from_control_deps { { 24 -> 8, 8 -> 9, 9 -> 26, 14 -> 15, 15 -> 20 }, { 24
-> 8, 8 -> 10, 10 -> 11, 11 -> 27, 14 -> 15, 15 -> 20 }, { 24 -> 8, 8 -> 10, 10
-> 13, 13 -> 30, 14 -> 15, 15 -> 20 } }:
MEM[(const char *)input_27 + -1B] != 101 && MEM[(const char
*)input_27 + -1B] <= 101) && MEM[(const char *)input_27 + -1B] == 50) &&
MEM[(const char *)input_74 + 1B] == 10) && _72 == 101 || MEM[(const char
*)input_27 + -1B] != 101 && MEM[(const char *)input_27 + -1B] > 101) &&
MEM[(const char *)input_27 + -1B] <= 115) && MEM[(const char *)input_27 + -1B]
> 112) && MEM[(const char *)input_74 + 1B] == 10) && _72 == 101) ||
MEM[(const char *)input_2
[Bug tree-optimization/101778] bogus -Wstringop-overread on strncmp of a larger array and a shorter string with a large bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101778 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Known to fail||11.1.0, 12.0 Blocks||97048 --- Comment #1 from Martin Sebor --- The false positive has been issued since GCC 11.0 when the warning was introduced (it was -Wstringop-overflow then). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048 [Bug 97048] [meta-bug] bogus/missing -Wstringop-overread warnings
[Bug tree-optimization/101778] New: bogus -Wstringop-overread on strncmp of a larger array and a shorter string with a large bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101778
Bug ID: 101778
Summary: bogus -Wstringop-overread on strncmp of a larger array
and a shorter string with a large bound
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
In the test case below the call to strncmp() is required to read no more than 3
characters from a regardless of the bound because the length of the string
literal is 2. GCC folds the call to strcmp() (which is safe) but then
-Wstringop-overread triggers during expansion because at that time the warning
doesn't consider the length of the literal as bounding the read from the array.
The text of the warning is technically correct but its description in the
manual ("Warn for calls to string manipulation functions such as memchr, or
strcpy that are determined to read past the end of the source sequence") makes
it clear it's a false positive.
$ cat b.c && gcc -S -fdump-tree-optimized=/dev/stdout b.c
extern int strncmp (const char*, const char*, __SIZE_TYPE__);
const char a[3] = "abc";
int f (void)
{
const char *s = a;
return strncmp (s, "12", 4); // bogus warning
}
;; Function f (f, funcdef_no=0, decl_uid=1948, cgraph_uid=1, symbol_order=1)
int f ()
{
const char * s;
int D.1952;
int _3;
:
s_1 = &a;
_3 = __builtin_strcmp (s_1, "12");
:
:
return _3;
}
b.c: In function ‘f’:
b.c:8:10: warning: ‘__builtin_strcmp’ argument missing terminating nul
[-Wstringop-overread]
8 | return strncmp (s, "12", 4); // bogus warning
| ^~~~
b.c:3:12: note: referenced argument declared here
3 | const char a[3] = "abc";
|^
[Bug c++/101747] Two-argument version of attribute malloc does not perform overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101747 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-08-03 CC||msebor at gcc dot gnu.org Keywords||rejects-valid Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- I suppose the return type of the allocator could be used for the disambiguation. The difficulty here is that the attribute handler is in code shared by the C and C++ front ends with no good way to call a language-specific routine to do overload resolution. Maybe the attribute should accept a string with the mangled name of the function in addition to a function name. IIRC, attribute copy has the same limitation.
[Bug tree-optimization/101741] [12 Regression] ICE in fold_stmt, at gimple-range-fold.cc:541 since r12-2517-g1ce0b26e6e1e6c34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101741 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Keywords|ice-on-invalid-code |ice-on-valid-code --- Comment #4 from Martin Sebor --- I believe invalid in the keyword means strictly syntactically invalid, not undefined as a result of a semantic constraint (e.g., defining a standard function; GCC normally handles that gracefully).
[Bug testsuite/101688] g++.dg/warn/Wstringop-overflow-4.C fails on 32-bit archs with new jump threader
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101688 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Fixed in r12-2707.
[Bug testsuite/101688] g++.dg/warn/Wstringop-overflow-4.C fails on 32-bit archs with new jump threader
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101688 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|--- |12.0 Component|middle-end |testsuite Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Host|x86-64 with -m32, ppc64 |i686-*-* powerpc-*-* |with -m32 |
[Bug middle-end/101688] g++.dg/warn/Wstringop-overflow-4.C fails on 32-bit archs with new jump threader
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101688
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2021-08-03
Status|UNCONFIRMED |NEW
Keywords||diagnostic
--- Comment #2 from Martin Sebor ---
I can confirm the unexpected warnings but the reason for them isn't that
they're somehow confused. They're correct for the emitted IL.
Here's a small example:
$ cat pr101688.C && gcc -O2 -S -Wall -m32 pr101688.C
char *p, *q;
void f (int n)
{
if (n < 0)
n = 0;
p = (char*)new int[n];
*p = 0;
q = (char*)new int[n + 1];
*q = 0;
}
pr101688.C: In function ‘void f(int)’:
pr101688.C:9:6: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
9 | *p = 0;
| ~~~^~~
pr101688.C:8:23: note: destination object of size 0 allocated by ‘operator new
[]’
8 | p = (char*)new int[n];
| ^
The IL the warning is issued for is the following:
[local count: 1073741824]:
if (n_3(D) < 0)
goto ; [25.50%]
...
[local count: 273804168]:
_29 = operator new [] (0); <<< zero-sized allocation
p = _29;
MEM[(char *)_29] = 0; <<< -Wstringop-overflow
goto ; [100.00%]
The invalid code in bb 8 is first seen in the vrp1 dump:
[local count: 1073741824]:
if (n_3(D) < 0)
goto ; [25.50%]
...
[local count: 273804168]:
# n_25 = PHI <0(2)>
# n.1_26 = PHI <0(2)>
iftmp.0_27 = n.1_26 * 4;
_29 = operator new [] (iftmp.0_27);
p = _29;
MEM[(char *)_29] = 0;
When i == 0, the first allocation creates a zero-sized object which then
results in an out-of-bounds store. If this were real code (as opposed to a
test) I'd say the code is unsafe and warning for it is justified. What's
unhelpful here is that the warning that ends up issued doesn't make the problem
clear.
[Bug testsuite/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 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Last reconfirmed||2021-08-03 Target Milestone|--- |11.3 Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Here's the discussion for reference: https://sourceware.org/pipermail/libc-alpha/2021-April/125589.html I said I'd look into elaxing how the combination of void* and attribute access none is handled in GCC 11.2 but it slipped my mind. Let me do that for 11.3.
[Bug middle-end/101734] missing warning reading from a write-only object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101734 Martin Sebor changed: What|Removed |Added Keywords||patch Target Milestone|--- |12.0 --- Comment #1 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576544.html
[Bug middle-end/101734] missing warning reading from a write-only object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101734 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-08-02
[Bug middle-end/101734] New: missing warning reading from a write-only object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101734
Bug ID: 101734
Summary: missing warning reading from a write-only object
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 write_only mode to attribute access is documented like so:
The write_only access mode applies to arguments of pointer types without the
const qualifier. It specifies that the pointer to which it applies is used to
write to the referenced object but not read from it.
A function that uses the pointer to read the refdrenced object might rely on
the contents of uninitialized memory and so such attempts should be diagnosed.
GCC 11 (and 12) fails to do so:
$ cat z.c && gcc -O2 -S -Wall z.c
__attribute__ ((access (write_only, 1, 2)))
int f (int *p, int n)
{
return *p;
}
$
The same goes for attribute none.
[Bug tree-optimization/58169] missed load PRE related to array index truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58169
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
CC||msebor at gcc dot gnu.org
--- Comment #1 from Martin Sebor ---
The latest trunk emits the following -m32 code (AVR is the same) with just two
loads as expected so I think this is resolved:
long long int NumSift (long long int * array, long long unsigned int k)
{
unsigned int _1;
unsigned int _2;
long long int * _3;
long long int _4;
unsigned int _5;
unsigned int _6;
long long int * _7;
long long int _8;
unsigned int _21;
unsigned int _23;
long long int * _25;
long long int pretmp_27;
long long int prephitmp_28;
[local count: 1073741824]:
_1 = (unsigned int) k_13(D);
_2 = _1 * 8;
_3 = array_14(D) + _2;
_4 = *_3;
_5 = _1 + 1;
_6 = _5 * 8;
_7 = array_14(D) + _6;
_8 = *_7;
if (_4 < _8)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
k_16 = k_13(D) + 1;
_21 = (unsigned int) k_16;
_23 = _21 * 8;
_25 = array_14(D) + _23;
pretmp_27 = *_25;
[local count: 1073741824]:
# k_12 = PHI
# prephitmp_28 = PHI <_4(2), pretmp_27(3)>
return prephitmp_28;
}
[Bug tree-optimization/101525] "out of the bounds" warning for an innocuous memset call with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101525 Martin Sebor changed: What|Removed |Added Blocks||56456 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-08-02 --- Comment #2 from Martin Sebor --- GCC 12 issues a bunch of warnings for this file (below) but the one mentioned in comment #0 is the first one below. It's issued for the following IL: vector(2) long int * vectp.5288; ... vectp.5288_337 = &it_140(D)->position.charpos; <<< memset accesses vect_saved_pos_charpos_84.5289_336 = MEM [(long int *)vectp.5288_337]; saved_pos$charpos_84 = it_140(D)->position.charpos; saved_pos$bytepos_83 = it_140(D)->position.bytepos; saved_object_148 = it_140(D)->object; it_140(D)->what = 0; memset (vectp.5288_337, 0, 16); <<< warning here it_140(D)->object = 0B; it_140(D)->len = 1; So vectp.5288_337 points to it->position's charpos member but the memset clears the whole struct. To detect buffer overflow the access warnings assume that the accesses in the IL they work with correspond to those in the original source (in fact all warnings necessarily assume the IL corresponds to the source code). Optimizations that substitute one subobject for another (e.g., FRE which introduces this IL) reak this assumption and trigger false positives. There's nothing the warning can do in these cases except to give up on detecting buffer overflow in member accesses. That's obviously not desirable. But the problem can be solved by changing optimization to refer to subobjects by their offsets from the beginning of the enclosing object instead of by their name. In other words, in the above, GCC should emit: vectp.5288_337 = &it_140(D)->position; This has no adverse impact on optimization. The last time we have discussed this I said I'd look into it for GCC 12 and I still plan (hope) to. $ gcc -O3 -S -Warray-bounds=2 -flto=2 -ffat-lto-objects -fdump-tree-vrp1 xdisp.preprocessed.c.c xdisp.preprocessed.c.c: In function ‘append_space_for_newline’: xdisp.preprocessed.c.c:95847:7: warning: ‘memset’ offset [2352, 2359] from the object at ‘it_138(D)’ is out of the bounds of referenced subobject ‘charpos’ with type ‘long int’ at offset 2344 [-Warray-bounds] 95847 | memset (&it->position, 0, sizeof it->position); | ^~ xdisp.preprocessed.c.c:16291:13: note: subobject ‘charpos’ declared here 16291 | ptrdiff_t charpos; | ^~~ xdisp.preprocessed.c.c: In function ‘extend_face_to_end_of_line’: xdisp.preprocessed.c.c:96182:8: warning: ‘memset’ offset [2352, 2359] from the object at ‘it_309(D)’ is out of the bounds of referenced subobject ‘charpos’ with type ‘long int’ at offset 2344 [-Warray-bounds] 96182 |memset (&it->position, 0, sizeof it->position); |^~ xdisp.preprocessed.c.c:16291:13: note: subobject ‘charpos’ declared here 16291 | ptrdiff_t charpos; | ^~~ xdisp.preprocessed.c.c:96216:5: warning: ‘memset’ offset [2352, 2359] from the object at ‘it_309(D)’ is out of the bounds of referenced subobject ‘charpos’ with type ‘long int’ at offset 2344 [-Warray-bounds] 96216 | memset (&it->position, 0, sizeof it->position); | ^~ xdisp.preprocessed.c.c:16291:13: note: subobject ‘charpos’ declared here 16291 | ptrdiff_t charpos; | ^~~ xdisp.preprocessed.c.c:96267:8: warning: ‘memset’ offset [2352, 2359] from the object at ‘it_309(D)’ is out of the bounds of referenced subobject ‘charpos’ with type ‘long int’ at offset 2344 [-Warray-bounds] 96267 |memset (&it->position, 0, sizeof it->position); |^~ xdisp.preprocessed.c.c:16291:13: note: subobject ‘charpos’ declared here 16291 | ptrdiff_t charpos; | ^~~ xdisp.preprocessed.c.c:96298:7: warning: ‘memset’ offset [2352, 2359] from the object at ‘it_309(D)’ is out of the bounds of referenced subobject ‘charpos’ with type ‘long int’ at offset 2344 [-Warray-bounds] 96298 | memset (&it->position, 0, sizeof it->position); | ^~ xdisp.preprocessed.c.c:16291:13: note: subobject ‘charpos’ declared here 16291 | ptrdiff_t charpos; | ^~~ In function ‘SDATA’, inlined from ‘SSDATA’ at xdisp.preprocessed.c.c:5996:19, inlined from ‘tty_handle_tab_bar_click’ at xdisp.preprocessed.c.c:90014:19: xdisp.preprocessed.c.c:5990:31: warning: array subscript 0 is outside array bounds of ‘struct Lisp_X[9223372036854775807]’ [-Warray-bounds] 5990 | return XSTRING (string)->u.s.data;
[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 CC||msebor at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-08-02 Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- The ICE was introduced in g:98f1f9f38c45218c06200feb1939c9433a2ab6ca.
[Bug lto/79062] -Walloca-larger-than and -Wformat-overflow warnings disabled by -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79062
Martin Sebor changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #9 from Martin Sebor ---
The same problem affects _FORTIFY_SOURCE. Since this effectively disables
compile-time buffer overflow detection for the sprintf family of functions I'm
bumping Importance up to P2. (The runtime prevention still works.)
$ (set -x && cat pr79062.c && gcc -D_FORTIFY_SOURCE=2 -O2 -Wall -flto -c
pr79062.c && gcc -D_FORTIFY_SOURCE=2 -O2 -Wall -flto pr79062.o && ./a.out)
+ cat pr79062.c
#include
#include
int main (void)
{
char *d = (char*)alloca (2);
int n = sprintf (d, "%i", 123); // missing warning with -flto
puts (d);
if (n > 1)
abort ();
}
+ gcc -D_FORTIFY_SOURCE=2 -O2 -Wall -flto -c pr79062.c
+ gcc -D_FORTIFY_SOURCE=2 -O2 -Wall -flto pr79062.o
+ ./a.out
*** buffer overflow detected ***: ./a.out terminated
[Bug lto/79062] -Walloca-larger-than and -Wformat-overflow warnings disabled by -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79062
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2017-01-12 00:00:00 |2021-7-30
Known to fail||10.2.0, 11.2.0, 12.0,
||7.3.0, 8.3.0, 9.2.0
--- Comment #8 from Martin Sebor ---
Reconfirmed with GCC 12 for the missing -Wformat-overflow:
$ (cc='/build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc'; set -x && cat
pr79062.c && $cc -O2 -Wall -flto -c pr79062.c && $cc -O2 -Wall -flto pr79062.o
&& valgrind ./a.out)
+ cat pr79062.c
int main (void)
{
char *d = (char*)__builtin_alloca (2);
int n = __builtin_sprintf (d, "%i", 123); // missing warning with -flto
__builtin_puts (d);
if (n > 1)
__builtin_abort ();
}
+ /build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc -O2 -Wall -flto -c
pr79062.c
+ /build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc -O2 -Wall -flto pr79062.o
+ valgrind ./a.out
==5314== Memcheck, a memory error detector
==5314== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==5314== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==5314== Command: ./a.out
==5314==
123
==5314==
==5314== Process terminating with default action of signal 6 (SIGABRT): dumping
core
==5314==at 0x48A357F: raise (in /usr/lib64/libc-2.28.so)
==5314==by 0x488D894: abort (in /usr/lib64/libc-2.28.so)
==5314==by 0x4010A6: main (in /ssd/build/tmp/a.out)
==5314==
==5314== HEAP SUMMARY:
==5314== in use at exit: 0 bytes in 0 blocks
==5314== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==5314==
==5314== All heap blocks were freed -- no leaks are possible
==5314==
==5314== For lists of detected and suppressed errors, rerun with: -s
==5314== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[Bug middle-end/101679] triplicate warning offset outside bounds of constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101679 --- Comment #2 from Martin Sebor --- For the code in comment #1, the first warning is issued from the front end, the second one from the Gimplifier, and the last one just before expansion. The first one still has the right location. The second one has the location of the call because that's what's being folded. The third one has no location because it's being issued for a STRING_CST so the code substitutes input_location.
[Bug middle-end/101679] triplicate warning offset outside bounds of constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101679
Martin Sebor changed:
What|Removed |Added
Summary|duplicate warning offset|triplicate warning offset
|outside bounds of constant |outside bounds of constant
|string |string
--- Comment #1 from Martin Sebor ---
An even better example of the same problem. It also illustrates how the
warning location gets progressively worse:
$ cat a.c && gcc -S -Wall a.c
const char s[0] = { };
int f (void)
{
return __builtin_strlen (s);
}
a.c: In function ‘f’:
a.c:5:28: warning: offset ‘0’ outside bounds of constant string
[-Warray-bounds]
5 | return __builtin_strlen (s);
|^
a.c:1:12: note: ‘s’ declared here
1 | const char s[0] = { };
|^
a.c:5:10: warning: offset ‘0’ outside bounds of constant string
[-Warray-bounds]
5 | return __builtin_strlen (s);
| ^~~~
a.c:1:12: note: ‘s’ declared here
1 | const char s[0] = { };
|^
a.c:3:5: warning: offset ‘0’ outside bounds of constant string [-Warray-bounds]
3 | int f (void)
| ^
a.c:1:12: note: ‘s’ declared here
1 | const char s[0] = { };
|^
[Bug middle-end/101679] New: duplicate warning offset outside bounds of constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101679
Bug ID: 101679
Summary: duplicate warning offset outside bounds of constant
string
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: ---
Only one instance of -Warray-bounds should be reported the access below but GCC
issues two. The warning is issued from c_strlen() with the first instance
during lowering and the second during (or just before) expansion. The first
instance calls suppress_warning(arg, OPT_Warray_bounds) which is checked again
before issuing the second instance by calling warning_suppressed_p (arg,
OPT_Warray_bounds). The problem is that the first time arg is an ADDR_EXPR but
VAR_DECL the second. Stripping the ADDR_EXPR and disabling the warning for its
operand is not a solution because it would disable warnings for invalid uses of
the same operand in other statements, both in the same function or (for global
variables) in others.
$ cat a.c && gcc -S -Wall a.c
const char s0[0] = { };
char* f (char *d)
{
return __builtin_strcpy (d, s0);
}
a.c: In function ‘f’:
a.c:5:31: warning: offset ‘0’ outside bounds of constant string
[-Warray-bounds]
5 | return __builtin_strcpy (d, s0);
| ^~
a.c:1:12: note: ‘s0’ declared here
1 | const char s0[0] = { };
|^~
a.c:5:10: warning: offset ‘0’ outside bounds of constant string
[-Warray-bounds]
5 | return __builtin_strcpy (d, s0);
| ^~~~
a.c:1:12: note: ‘s0’ declared here
1 | const char s0[0] = { };
|^~
[Bug middle-end/101671] pr83510 fails with -Os because threader confuses -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101671
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Last reconfirmed||2021-07-29
Keywords||diagnostic
Summary|pr83510 fails because |pr83510 fails with -Os
|threader confuses |because threader confuses
|-Warray-bounds |-Warray-bounds
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Martin Sebor ---
Confirmed. I've extracted the test case that fails from the bigger test.
Rather than xfailing the whole test I think it would be better to split out
just the failing case and/or xfail just that assertion. Unless you expect the
others to start failing too due to some changes you still have planned?
$ cat a.c && gcc -Os -S -Wall a.c
extern int f (void);
extern void sink (unsigned int);
unsigned int a[10];
static unsigned int g (int i, int j)
{
if (i == 9)
return j;
else if (i == 10)
return a[i];// no warning here
return 0;
}
void test_g (int j)
{
for (int i = 0; i < 10; i++)
{
if (f ())
sink (g (i, j));
}
}
static unsigned int h (int i, int j)
{
switch (i)
{
case 9:
return j;
case 10:
return a[i]; // { dg-bogus "-Warray-bounds" }
}
return 0;
}
void test_h (int j)
{
for (int i = 0; i < 10; i++)
{
if (f ())
sink (h (i, j));
}
}
In function ‘h’,
inlined from ‘test_h’ at a.c:41:2:
a.c:31:15: warning: array subscript 10 is above array bounds of ‘unsigned
int[10]’ [-Warray-bounds]
31 | return a[i]; // { dg-bogus "-Warray-bounds" }
| ~^~~
a.c: In function ‘test_h’:
a.c:4:14: note: while referencing ‘a’
4 | unsigned int a[10];
| ^
[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101674 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Target|ppc64*-*-* |powerpc64*-*-* Last reconfirmed||2021-07-29 CC||msebor at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- I can confirm the test fails (despite the xfail): FAIL: gcc.dg/uninit-pred-9_b.c bogus warning (test for bogus messages, line 25) The xfail target should probably be powerpc64*-*-*. Since the failure is on line 25 would it make sense to xfail just that assertion?
[Bug middle-end/101665] -fno-delete-null-pointer checks ineffective for attribute nonnull parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101665 Martin Sebor changed: What|Removed |Added Last reconfirmed||2021-07-29 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100404 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Keywords||documentation --- Comment #2 from Martin Sebor --- This is essentially a duplicate of pr100404 which was resolved as invalid, but I think it's possible to do better: at a minimum, updating the documentation might help. Issuing a warning when both attributes are set on the same function indicating that one is ignored (as is normally done) would be even better but wouldn't help if -fno-delete-null-pointer-checks is set by a #pragma or on the command line. Let me see what I can do.
[Bug middle-end/101665] New: -fno-delete-null-pointer checks ineffective for attribute nonnull parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101665
Bug ID: 101665
Summary: -fno-delete-null-pointer checks ineffective for
attribute nonnull parameters
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: ---
As discussed in
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576225.html:
> The manual says -fno-delete-null-pointer-checks is supposed to
> prevent the removal of the null function argument test so I'd
> expect adding attribute optimize ("no-delete-null-pointer-checks")
> to the definition of the function to have that effect but in my
> testing it didn't work (and didn't give a warning for the two
> attributes on the same declarataion).
$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout a.c
__attribute__ ((nonnull))
void f (int *);
#pragma GCC optimize "no-delete-null-pointer-checks"
__attribute__ ((optimize ("no-delete-null-pointer-checks")))
void f (int *p)
{
if (p == 0)
__builtin_abort ();
}
a.c: In function ‘f’:
a.c:9:6: warning: ‘nonnull’ argument ‘p’ compared to NULL [-Wnonnull-compare]
9 | if (p == 0)
| ^
;; Function f (f, funcdef_no=0, decl_uid=1943, cgraph_uid=1, symbol_order=0)
__attribute__((optimize ("no-delete-null-pointer-checks",
"no-delete-null-pointer-checks")))
__attribute__((nonnull))
void f (int * p)
{
[local count: 1073741824]:
return;
}
[Bug tree-optimization/101494] [11 Regression] -Wmaybe-uninitialized false alarm with memrchr of size 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101494 --- Comment #7 from Martin Sebor --- Fixed in GCC 12 by r12-2583. Will backport to GCC 11.
[Bug middle-end/101601] [12 Regression] -Warray-bounds triggers error: arrays of functions are not meaningful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101601 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Sebor --- Fixed in r12-2582.
[Bug target/101662] New: FAIL: gcc.target/i386/pr91446.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101662 Bug ID: 101662 Summary: FAIL: gcc.target/i386/pr91446.c Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- Today's build shows the following failure: Executing on host: /ssd/build/gcc-trunk/gcc/xgcc -B/ssd/build/gcc-trunk/gcc/ /src/gcc/trunk/gcc/testsuite/gcc.target/i386/pr91446.c -fdiagnostics-plain-output -O2 -march=skylake -ftree-slp-vectorize -mtune-ctrl=^sse_typeless_stores -ffat-lto-objects -fno-ident -S -o pr91446.s (timeout = 300) spawn -ignore SIGHUP /ssd/build/gcc-trunk/gcc/xgcc -B/ssd/build/gcc-trunk/gcc/ /src/gcc/trunk/gcc/testsuite/gcc.target/i386/pr91446.c -fdiagnostics-plain-output -O2 -march=skylake -ftree-slp-vectorize -mtune-ctrl=^sse_typeless_stores -ffat-lto-objects -fno-ident -S -o pr91446.s Executing on host: /ssd/build/gcc-trunk/gcc/xgcc -B/ssd/build/gcc-trunk/gcc/ exceptions_enabled18108.cc-fdiagnostics-plain-output -S -o exceptions_enabled18108.s(timeout = 300) spawn -ignore SIGHUP /ssd/build/gcc-trunk/gcc/xgcc -B/ssd/build/gcc-trunk/gcc/ exceptions_enabled18108.cc -fdiagnostics-plain-output -S -o exceptions_enabled18108.s PASS: gcc.target/i386/pr91446.c (test for excess errors) gcc.target/i386/pr91446.c: vmovdqa[^\n\r]*xmm[0-9] found 0 times FAIL: gcc.target/i386/pr91446.c scan-assembler-times vmovdqa[^\n\r]*xmm[0-9] 2 testcase /src/gcc/trunk/gcc/testsuite/gcc.target/i386/i386.exp completed in 1 seconds
[Bug testsuite/101661] New: UNRESOLVED: gcc.dg/ipa/remref-6.c scan-ipa-dump inline "Removed a reference"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101661 Bug ID: 101661 Summary: UNRESOLVED: gcc.dg/ipa/remref-6.c scan-ipa-dump inline "Removed a reference" Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- The gcc.dg/ipa/remref-6.c test fails in a recent build due to a missing command line option: spawn -ignore SIGHUP /ssd/build/gcc-master/gcc/xgcc -B/ssd/build/gcc-master/gcc/ /ssd/src/gcc/master/gcc/testsuite/gcc.dg/ipa/remref-6.c -fdiagnostics-plain-output -O2 -fno-early-inlining -fno-ipa-cp -fdump-tree-optimized -S -o remref-6.s Executing on host: /ssd/build/gcc-master/gcc/xgcc -B/ssd/build/gcc-master/gcc/ exceptions_enabled3201.cc-fdiagnostics-plain-output -S -o exceptions_enabled3201.s(timeout = 300) spawn -ignore SIGHUP /ssd/build/gcc-master/gcc/xgcc -B/ssd/build/gcc-master/gcc/ exceptions_enabled3201.cc -fdiagnostics-plain-output -S -o exceptions_enabled3201.s PASS: gcc.dg/ipa/remref-6.c (test for excess errors) gcc.dg/ipa/remref-6.c: dump file does not exist UNRESOLVED: gcc.dg/ipa/remref-6.c scan-ipa-dump inline "Removed a reference" gcc.dg/ipa/remref-6.c: dump file does not exist UNRESOLVED: gcc.dg/ipa/remref-6.c scan-ipa-dump inline "replaced it with LOAD" PASS: gcc.dg/ipa/remref-6.c scan-tree-dump-not optimized "builtin_exp" testcase /ssd/src/gcc/master/gcc/testsuite/gcc.dg/ipa/ipa.exp completed in 0 seconds === gcc Summary === # of expected passes2 # of unresolved testcases 2
[Bug fortran/101660] New: FAIL: gfortran.dg/bind_c_array_params_3.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101660 Bug ID: 101660 Summary: FAIL: gfortran.dg/bind_c_array_params_3.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: --- In a recent x86_64 build I see a number of failures in the gfortran test suite: FAIL: gfortran.dg/bind_c_array_params_3.f90 (6: -12) FAIL: gfortran.dg/ISO_Fortran_binding_10.f90 (6: -12) FAIL: gfortran.dg/ISO_Fortran_binding_11.f90 (6: -12) FAIL: gfortran.dg/ISO_Fortran_binding_12.f90 (6: -12) FAIL: gfortran.dg/ISO_Fortran_binding_15.f90 (6: -12) FAIL: gfortran.dg/ISO_Fortran_binding_16.f90 (6: -12) FAIL: gfortran.dg/ISO_Fortran_binding_17.f90 (6: -12) FAIL: gfortran.dg/ISO_Fortran_binding_18.f90 (6: -12) FAIL: gfortran.dg/ISO_Fortran_binding_1.f90 (6: -12) FAIL: gfortran.dg/ISO_Fortran_binding_3.f90 (6: -12) FAIL: gfortran.dg/ISO_Fortran_binding_5.f90 (6: -12) FAIL: gfortran.dg/ISO_Fortran_binding_6.f90 (6: -12) FAIL: gfortran.dg/ISO_Fortran_binding_7.f90 (6: -12) FAIL: gfortran.dg/ISO_Fortran_binding_8.f90 (6: -12) FAIL: gfortran.dg/ISO_Fortran_binding_9.f90 (6: -12) FAIL: gfortran.dg/iso_fortran_binding_uint8_array.f90 (6: -12) FAIL: gfortran.dg/pr93524.f90 (6: -12) FAIL: gfortran.dg/PR94327.f90 (6: -12) FAIL: gfortran.dg/PR94331.f90 (6: -12) The failures have also been reported here: https://gcc.gnu.org/pipermail/gcc-testresults/2021-July/709815.html Most (all?) of the failures are due to: gcc/testsuite/gfortran.dg/bind_c_array_params_3_aux.c:8:10: fatal error: ISO_Fortran_binding.h: No such file or directory compilation terminated. compiler exited with status 1 FAIL: gfortran.dg/bind_c_array_params_3.f90 -O0 (test for excess errors) Excess errors: gcc/testsuite/gfortran.dg/bind_c_array_params_3_aux.c:8:10: fatal error: ISO_Fortran_binding.h: No such file or directory compilation terminated. UNRESOLVED: gfortran.dg/bind_c_array_params_3.f90 -O0 compilation failed to produce executable
[Bug c/99295] [9 Regression] documentation on __attribute__((malloc)) is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99295 Martin Sebor changed: What|Removed |Added Known to fail|10.2.1 | Summary|[9/10 Regression] |[9 Regression] |documentation on|documentation on |__attribute__((malloc)) is |__attribute__((malloc)) is |wrong |wrong Target Milestone|11.3|9.5 --- Comment #10 from Martin Sebor --- Backported to GCC 10.
[Bug c++/101480] [11/12 Regression] Miscompiled code involving operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #16 from Martin Sebor --- (In reply to Richard Biener from comment #14) ... > the testcase does > > m = i; > p = (int*) new unsigned char [sizeof (int) * m]; > > for (int i = 0; i < m; i++) > new (p + i) int (); > > and we likely have to assume that 'new' changes 'm'. Why? Because of the flow-insensitivity of the alias analysis? m is a member of the class whose ctor has the loop above. Neither the enclosing object nor the member actually escapes (the operator new to which p is passed in the loop is the nonreplaceable placement new), so there is no way it can be changed.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 101584, which changed state. Bug 101584 Summary: missing -Wuninitialized with an allocated object after a built-in call https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101584 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/101584] missing -Wuninitialized with an allocated object after a built-in call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101584 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED --- Comment #3 from Martin Sebor --- Done for GCC 12.
[Bug c/101585] [11 Regression] Bad interaction of -fsanitize=undefined and -Wvla-parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101585 Martin Sebor changed: What|Removed |Added Summary|[11/12 Regression] Bad |[11 Regression] Bad |interaction of |interaction of |-fsanitize=undefined and|-fsanitize=undefined and |-Wvla-parameters|-Wvla-parameters Known to fail|12.0| --- Comment #3 from Martin Sebor --- Fixed in GCC 12. Will backport to GCC 11.
[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574
--- Comment #8 from Martin Sebor ---
The symptom in comment #6 does look similar to the problem discussed in
pr101292. I haven't debugged it yet but when developing the warning control
patch I struggled with keeping the garbage collector from collecting the global
hash map between location_t and the nowarn_spec_t struct. My suspicion is that
either the annotation on the hash_map isn't correct (it's a simple GTY("") so
it's hard to imagine what might be wrong with it), or the integration with the
garbage collector is incomplete (I had to change the hash_map definition itself
to let hash_map even compile).
[Bug middle-end/101600] [12 Regression] Spurious -Warray-bounds downcasting a polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101600
--- Comment #2 from Martin Sebor ---
There's another bug here that can be reproduced with the following slightly
modified version of the original test case:
$ cat pr101600-c2.C && /build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc -O2
-S -Wall pr101600-c2.C
struct S1 { virtual ~S1(); };
struct S2 { int m; };
struct S3 { virtual ~S3(); };
struct S4: S1, S2, S3 {};
int f1();
void f2 (S3 *);
S4 s4;
void f3 (void)
{
S2 *p = &s4;
for (int i = f1(); f1();)
{
if (i == 0)
{
p = nullptr;
break;
}
}
f2 (static_cast(p));
}
pr101600-c2.C: In function ‘void f3()’:
pr101600-c2.C:25:6: warning: array subscript 0 is outside array bounds of ‘S2
[2305843009213693951]’ [-Warray-bounds]
25 | f2 (static_cast(p));
| ~~~^~
pr101600-c2.C:4:8: note: at offset -8 into object ‘S4::’ of size 4
4 | struct S4: S1, S2, S3 {};
|^~
A simpler (but contrived) C test case goes something like this:
$ cat u.c && gcc -O2 -S -Wall u.c
struct A { int i, j; } a;
int f (void);
void g (int);
void h (void)
{
void *p = &a.j;
for (int i = f (); f (); )
if (!i)
{
p = 0;
break;
}
int o = __builtin_offsetof (struct A, j);
struct A *q = (struct A*)((char*)p - o);
g (q->i);
}
u.c: In function ‘h’:
u.c:20:7: warning: array subscript 0 is outside array bounds of
‘void[9223372036854775807]’ [-Warray-bounds]
20 | g (q->i);
| ^~
u.c:1:19: note: at offset -4 into object ‘j’ of size 4
1 | struct A { int i, j; } a;
| ^
[Bug middle-end/101600] [12 Regression] Spurious -Warray-bounds downcasting a polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101600 Martin Sebor changed: What|Removed |Added Blocks||56456 Target Milestone|--- |12.0 Ever confirmed|0 |1 CC||msebor at gcc dot gnu.org Last reconfirmed||2021-07-23 Summary|Spurious -Warray-bounds |[12 Regression] Spurious ||-Warray-bounds downcasting ||a polymorphic pointer Known to work||11.1.0 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Known to fail||12.0 --- Comment #1 from Martin Sebor --- Thanks for the small test case! I can confirm the false positive. The IL looks (close to) the following: [local count: 80404472]: # p_1 = PHI if (p_1 != 0B) goto ; [100.00%] else goto ; [0.00%] [local count: 80404472]: iftmp.1_11 = &MEM[(struct S4 *)p_1 + -8B].D.2419; <<< -Warray-bounds except that p_1 is: p_1 = PHI <0B(3), p_9(D)(4)> The bug is in access_ref::get_ref () in not clearing the base0 flag, making -Warray-bounds think the pointer points to the first byte of a declared object. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug c/101605] New: bogus -Wvla-parameter in same bound expression with differently named parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101605
Bug ID: 101605
Summary: bogus -Wvla-parameter in same bound expression with
differently named parameters
Product: gcc
Version: 11.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: ---
Even with pr97548 and pr 101585 resolved there are a few outstanding
-Wvla-parameter false positives as the test case below shows:
$ (set -x && cat u.c && gcc -S -Wall u.c && gcc -S -Wall -fsanitize=undefined
u.c)
+ cat u.c
void f (int m, int (*)[m]);
void f (int n, int (*)[n]) { } // bogus warning with -fsanitize=undefined
void g (int m, int (*)[m + 1]);
void g (int n, int (*)[n + 1]) { } // bogus warning either way
+ gcc -S -Wall u.c
u.c:5:16: warning: mismatch in bound 1 of argument 2 declared as ‘int (*)[n +
1]’ [-Wvla-parameter]
5 | void g (int n, int (*)[n + 1]) { } // bogus warning either way
|^~
u.c:4:16: note: previously declared as ‘int (*)[m + 1]’
4 | void g (int m, int (*)[m + 1]);
|^~
+ gcc -S -Wall -fsanitize=undefined u.c
u.c:2:16: warning: mismatch in bound 1 of argument 2 declared as ‘int (*)[(long
int)(n) - 1]’ [-Wvla-parameter]
2 | void f (int n, int (*)[n]) { } // bogus warning with
-fsanitize=undefined
|^~
u.c:1:16: note: previously declared as ‘int (*)[(long int)(m) - 1]’
1 | void f (int m, int (*)[m]);
|^~
u.c:5:16: warning: mismatch in bound 1 of argument 2 declared as ‘int (*)[(long
int)(n + 1) - 1]’ [-Wvla-parameter]
5 | void g (int n, int (*)[n + 1]) { } // bogus warning either way
|^~
u.c:4:16: note: previously declared as ‘int (*)[(long int)(m + 1) - 1]’
4 | void g (int m, int (*)[m + 1]);
|^~
[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 Summary|bogus -Wvla-paramater |[11 Regression] bogus |warning when using const|-Wvla-paramater warning |for vla param |when using const for vla ||param --- Comment #5 from Martin Sebor --- I'll backport the patch into GCC 11.
[Bug c/97548] [11 Regression] bogus -Wvla-parameter on a bound expression involving a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97548
--- Comment #6 from Martin Sebor ---
The fix isn't very robust since it only handles redeclarations with VLA
parameters that involve bounds that have the same name but not nontrivial
expressions involving different names, like in this case:
$ cat pr97548-c6.c && gcc -S -Wall pr97548-c6.c
void g (int k, int [k + 1]);
void g (int m, int [m + 1]) { } // bogus warning
pr97548-c6.c:2:16: warning: argument 2 of type ‘int[m + 1]’ declared with
mismatched bound ‘m + 1’ [-Wvla-parameter]
2 | void g (int m, int [m + 1]) { } // bogus warning
|^~~
pr97548-c6.c:1:16: note: previously declared as ‘int[k + 1]’ with bound ‘k + 1’
1 | void g (int k, int [k + 1]);
|^~~
[Bug c/101604] [meta-bug] bogus/missing -Wvla-parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101604 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-07-23 Keywords||diagnostic, meta-bug Alias||Wvla-parameter
[Bug c/101604] New: [meta-bug] bogus/missing -Wvla-parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101604 Bug ID: 101604 Summary: [meta-bug] bogus/missing -Wvla-parameter Product: gcc Version: 11.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 for false positives and negatives in and enhancements for -Wvla-parameter, new in GCC 11.
[Bug c/97548] [11 Regression] bogus -Wvla-parameter on a bound expression involving a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97548 Martin Sebor changed: What|Removed |Added Summary|bogus -Wvla-parameter on a |[11 Regression] bogus |bound expression involving |-Wvla-parameter on a bound |a parameter |expression involving a ||parameter --- Comment #5 from Martin Sebor --- GCC 10 doesn't warn (it doesn't provide -Wvla-parameter) so it's a regression.
[Bug middle-end/101601] [12 Regression] -Warray-bounds triggers error: arrays of functions are not meaningful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101601 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED Keywords||diagnostic Target Milestone|--- |12.0 Summary|[12 Regression] -Wall is|[12 Regression] |reported as a build error |-Warray-bounds triggers |(not warning): error: |error: arrays of functions |arrays of functions are not |are not meaningful |meaningful | --- Comment #3 from Martin Sebor --- -Warray-bounds triggers the error while formatting the type of SSCall_fun. For simplicity, it converts the type of each singleton object into a one-element array of its type, but the code is wrong for function pointers.
[Bug c++/101597] [12 Regression] ICE in pretty-printer formatting an OBJ_TYPE_REF since r12-2132-ga110855667782dac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101597 Martin Sebor changed: What|Removed |Added Component|tree-optimization |c++ Summary|[12 Regression] ICE in evrp |[12 Regression] ICE in |since |pretty-printer formatting |r12-2132-ga110855667782dac |an OBJ_TYPE_REF since ||r12-2132-ga110855667782dac --- Comment #1 from Martin Sebor --- The ICE happens in a call to inform(..., "...%qE...", allocfn) with allocfn set to the OBJ_TYPE_REF argument below. The pretty-printer winds up passing the argument to resolve_virtual_fun_from_obj_type_ref() in cp/error.c which computes a null pointer that it eventually dereferences. The inform() call looks valid to me so the bug is most likely in the C++ frond end's pretty-printer. QI size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea987bd0 method basetype arg-types chain chain >>> pointer_to_this > public unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea987f18> arg:0 public unsigned type_6 DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set 5 canonical-type 0x7fffea952498 pointer_to_this > visited def_stmt _12 = *_11; version:12 ptr-info 0x7fffea9d5f30> arg:1 public unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set 7 canonical-type 0x7fffea98f000 pointer_to_this > def_stmt pluginScriptObjectFromPluginViewBase_pluginWidget.2_9 = ASSERT_EXPR ; version:9 ptr-info 0x7fffea9d9000> arg:2 constant 0>>
[Bug c/101585] [11/12 Regression] Bad interaction of -fsanitize=undefined and -Wvla-parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101585 Martin Sebor changed: What|Removed |Added Target Milestone|--- |11.2
[Bug c/101585] [11/12 Regression] Bad interaction of -fsanitize=undefined and -Wvla-parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101585 Martin Sebor changed: What|Removed |Added Summary|Bad interaction of |[11/12 Regression] Bad |-fsanitize=undefined and|interaction of |-Wvla-parameters|-fsanitize=undefined and ||-Wvla-parameters Ever confirmed|0 |1 CC||msebor at gcc dot gnu.org Known to fail||11.1.0, 12.0 Keywords||diagnostic Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-07-23 --- Comment #1 from Martin Sebor --- Confirmed. It looks like an oversight in r12-2329. The following fixes it: diff --git a/gcc/c-family/c-warn.c b/gcc/c-family/c-warn.c index 552a29f9944..7a50baedea9 100644 --- a/gcc/c-family/c-warn.c +++ b/gcc/c-family/c-warn.c @@ -3275,7 +3275,8 @@ warn_parm_ptrarray_mismatch (location_t origloc, tree curparms, tree newparms) /* Move on if the bounds look the same. */ if (!pcurbndpos && !pnewbndpos && curbnd && newbnd - && operand_equal_p (curbnd, newbnd, OEP_LEXICOGRAPHIC)) + && operand_equal_p (curbnd, newbnd, OEP_LEXICOGRAPHIC + | OEP_DECL_NAME)) continue; if ((curbnd && TREE_CODE (curbnd) != INTEGER_CST)
[Bug tree-optimization/101494] [11 Regression] -Wmaybe-uninitialized false alarm with memrchr of size 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101494 Martin Sebor changed: What|Removed |Added Keywords||patch Target Milestone|--- |11.2 --- Comment #4 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575862.html
[Bug tree-optimization/101584] missing -Wuninitialized with an allocated object after a built-in call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101584 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 Keywords||patch Last reconfirmed||2021-07-22 --- Comment #1 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575863.html
[Bug tree-optimization/101584] New: missing -Wuninitialized with an allocated object after a built-in call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101584
Bug ID: 101584
Summary: missing -Wuninitialized with an allocated object after
a built-in call
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The puts() calls below should be diagnosed by -Wuninitialized but aren't
because the alias analysis the warning relies on determines that the argument
and the result returned by malloc() or the VLA might alias each other.
$ cat a.c && gcc -O2 -S -Wall /build/tmp/a.c
void f (const char *s)
{
char *p = __builtin_malloc (__builtin_strlen (s));
__builtin_printf ("%s", s);
__builtin_puts (p); // missing -Wununitialized
}
void g (const char *s)
{
char a[__builtin_strlen (s)];
__builtin_printf ("%s", s);
__builtin_puts (a); // missing -Wununitialized
}
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 65178, which changed state. Bug 65178 Summary: incorrect -Wmaybe-uninitialized when using nested loops https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |7.0 Resolution|--- |FIXED CC||msebor at gcc dot gnu.org --- Comment #18 from Martin Sebor --- Bisection points to r246021 as the fix.
[Bug testsuite/101568] [12 regression] g++.dg/ipa/pr82352.C fails after r12-2338
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101568
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
Last reconfirmed||2021-7-22
Status|UNCONFIRMED |RESOLVED
Component|tree-optimization |testsuite
--- Comment #2 from Martin Sebor ---
The test calls a member operator new that returns an invalid address and then
stores data at that address. The warning correctly points that out.
class B
{
public :
void *operator new(size_t t) { return (void*)(42); };
};
Removing the bad definition avoids the warning.
[Bug tree-optimization/101494] [11 Regression] -Wmaybe-uninitialized false alarm with memrchr of size 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101494 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Summary|-Wmaybe-uninitialized false |[11 Regression] |alarm with memrchr of size |-Wmaybe-uninitialized false |0 |alarm with memrchr of size ||0 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Known to fail||11.1.0 --- Comment #3 from Martin Sebor --- It is a regression but only because GCC 10 doesn't check accesses to allocated storage to see if it's initialized.
[Bug tree-optimization/101494] -Wmaybe-uninitialized false alarm with memrchr of size 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101494
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2021-07-21
Status|UNCONFIRMED |NEW
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Martin Sebor ---
Confirmed. I think this exposes two underlying bugs: one that the
initialization isn't detected and another that the second argument to attribute
access isn't respected. A slightly enhanced test case:
$ cat b.c && gcc -O2 -S -Wall b.c
__attribute__ ((access (read_only, 1, 2))) void f (const void*, int);
void g (void)
{
char *p = __builtin_alloca (1);
*p = 0;
f (p, 0);// bogus -Wmaybe-uninitialized
}
void h (void)
{
char *p = __builtin_malloc (1);
f (p, 0);// bogus -Wmaybe-uninitialized
}
b.c: In function ‘g’:
b.c:7:3: warning: ‘p’ is used uninitialized [-Wuninitialized]
7 | f (p, 0);// bogus -Wmaybe-uninitialized
| ^~~~
b.c:1:49: note: in a call to ‘f’ declared with attribute ‘access (read_only, 1,
2)’ here
1 | __attribute__ ((access (read_only, 1, 2))) void f (const void*, int);
| ^
b.c: In function ‘h’:
b.c:13:3: warning: ‘p’ is used uninitialized [-Wuninitialized]
13 | f (p, 0);// bogus -Wmaybe-uninitialized
| ^~~~
b.c:1:49: note: in a call to ‘f’ declared with attribute ‘access (read_only, 1,
2)’ here
1 | __attribute__ ((access (read_only, 1, 2))) void f (const void*, int);
| ^
[Bug bootstrap/101379] libatomic arm build failure after r12-2132 due -Warray-bounds on a constant address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Martin Sebor --- Patch committed in r12-2438.
[Bug bootstrap/101379] libatomic arm build failure after r12-2132 due -Warray-bounds on a constant address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379 Martin Sebor changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #9 from Martin Sebor --- *** Bug 101553 has been marked as a duplicate of this bug. ***
[Bug bootstrap/101553] [12 Regression] armhf builds broken on -Werror=array-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101553 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Martin Sebor --- Patch was posted on 7/9 but hasn't yet been reviewed: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574880.html *** This bug has been marked as a duplicate of bug 101379 ***
[Bug c++/101219] [12 Regression] ice in perform_or_defer_access_check since r12-1804-g65870e75616ee435
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101219 --- Comment #7 from Martin Sebor --- Thanks for tracking down the change that triggers the ICE! I removed the suppression in a few cases where it served no apparent purpose (wasn't necessary to suppress warnings exercised by the test suite). This was not the primary but a secondary goal of the patch. Jason is probably in the best position to answer your questions, as well as why the removed suppression was there to begin with and whether it should be restored.
[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 Martin Sebor changed: What|Removed |Added Known to fail||11.1.0 Summary|[11/12 Regression] spurious |[11 Regression] spurious |warning writing to the |warning writing to the |result of stpcpy minus 1|result of stpcpy minus 1 --- Comment #5 from Martin Sebor --- Fixed in GCC 12.0. Will backport to 11 after a bit.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #32 from Martin Sebor --- *** Bug 101538 has been marked as a duplicate of this bug. ***
[Bug c/101538] [10/11/12 Regression] #pragma considered a statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101538 Martin Sebor changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED Keywords||wrong-code --- Comment #1 from Martin Sebor --- This a duplicate of pr63326. *** This bug has been marked as a duplicate of bug 63326 ***
[Bug c/101538] New: [10/11/12 Regression] #pragma considered a statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101538
Bug ID: 101538
Summary: [10/11/12 Regression] #pragma considered a statement
Product: gcc
Version: 11.1.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: ---
In the following test case both #pragma directives are expected to be evaluated
at compile-time with no effect on the emitted object code. Since the
conditional evaluates to zero the call to abort is expected to be eliminated.
Yet the emitted code shows that GCC treats the first #pragma as the empty
statement, thus ending the if statement. The end result is that the abort call
is made unconditionally. In the second instance, the unknown #pragma is
ignored and the code behaves as expected. That there's a difference between
the two is only hinted on by the -Wunknown-pragmas warning when it's enabled.
Clang and ICC behave as expected, as does G++ and GCC 4.1 (which doesn't
recognize #pragma message).
This was noticed when using #pragma GCC diagnostic and noted here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575613.html
$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout a.c
void f (void)
{
if (""['\0'])
#pragma message "Gotcha!"
__builtin_abort ();
}
void g (void)
{
if (""['\0'])
#pragma "Okay"
__builtin_abort ();
}
a.c: In function ‘f’:
a.c:4:9: note: ‘#pragma message: Gotcha!’
4 | #pragma message "Gotcha!"
| ^~~
a.c: In function ‘g’:
a.c:11: warning: ignoring ‘#pragma "Okay" ’ [-Wunknown-pragmas]
11 | #pragma "Okay"
|
;; Function f (f, funcdef_no=0, decl_uid=1943, cgraph_uid=1, symbol_order=0)
(unlikely executed)
void f ()
{
[count: 0]:
__builtin_abort ();
}
;; Function g (g, funcdef_no=1, decl_uid=1946, cgraph_uid=2, symbol_order=1)
void g ()
{
[local count: 1073741824]:
return;
}
