https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80806
Martin Sebor changed:
What|Removed |Added
Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72783
Martin Sebor changed:
What|Removed |Added
Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70816
Martin Sebor changed:
What|Removed |Added
Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70019
Martin Sebor changed:
What|Removed |Added
Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68047
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|msebor at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36159
Martin Sebor changed:
What|Removed |Added
Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|msebor at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104215
--- Comment #7 from Martin Sebor ---
The kernel false positive is discussed in bug 104069 comment 13. I don't think
it's related to this issue but you're of course right that this warning isn't
immune to false positives. That's true for all wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104215
--- Comment #5 from Martin Sebor ---
To "use" means to evaluate. The strict C semantics are that the realloc()
argument becomes indeterminate after the function has returned non-null,
whether or not the returned pointer is the same as the argum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104203
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104232
Martin Sebor changed:
What|Removed |Added
URL|https://bugzilla.redhat.com |https://bugzilla.redhat.com
gcc dot gnu.org |msebor at gcc dot
gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Keywords||diagnostic
Last reconfirmed||2022-01-25
URL
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The test case below was reduced from
https://bugzilla.redhat.com/show_bug.cgi?id=2043195 (it's been greatly
simplified). It shows a false positive caused b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104215
--- Comment #3 from Martin Sebor ---
I meant to say "C++ made it implementation-defined to use a pointer made
indeterminate by the pointee's lifetime having ended."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104215
--- Comment #2 from Martin Sebor ---
The use in your example is undefined in C (as is any other use of an
indeterminate pointer value). C++ made using pointers made it
implementation-defined a few years ago while still allowing for it to crash,
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
In the Warning options section the manual says this about -w and -Werror:
-w
Inhibit all warning messages.
-Werror
Make all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104203
Martin Sebor changed:
What|Removed |Added
Summary|[12 Regressions] huge |[12 Regressions] huge
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
This is to make a record of the false positive. I don't expect GCC to avoid
reordering the statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101831
Martin Sebor changed:
What|Removed |Added
Known to fail||11.2.0, 12.0
Summary|Spurious
||msebor at gcc dot gnu.org
--- Comment #4 from Martin Sebor ---
The warning points out the return statement in the dtor below, so it's doing
what it's been taught to do. I'm not sure why a dtor would have a return type
other than void or why it would need to return t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104203
--- Comment #9 from Martin Sebor ---
The underlying problem is that when the pointer_query class fails to determine
the pointer provenance for an SSA variable it doesn't update the cache, matter
how laborious the computation was. The next time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104203
--- Comment #7 from Martin Sebor ---
(In reply to Richard Biener from comment #5)
...
> Martin, can you add a new timevar to timevar.def and use that in
> pass_data_waccess please?
Will do. The bottleneck is the PHI handling in the access warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104203
Martin Sebor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #31 from Martin Sebor ---
I believe I understand what both of you are saying and (also) that the cache
behaves correctly. It stores offsets based on the pointer definition
statements. Here's a test that I think reproduces the condi
||msebor at gcc dot gnu.org
Last reconfirmed||2022-01-21
Blocks||56456
Summary|[12 Regression] Incorrectly |[12 Regression]
|identifying array bounds|-Warray-bounds for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #29 from Martin Sebor ---
>From memory: At use1 the cache is empty so go and find its definition and
record the offset at that point, with the pointer addition as the context. And
at use2 we look up the same offset. So use1 won't r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104148
--- Comment #3 from Martin Sebor ---
I suspect the unwanted suppression is because check_function_argument_recurse()
calls warning_suppressed_p (param) instead of warning_suppressed_p (param,
) (for each of the warnings it checks). So any other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #26 from Martin Sebor ---
(In reply to Andrew Macleod from comment #25)
...
> I also don't get the warning anymore on trunk.
>
> Is there still an issue here?
The strlen pass was converted to Ranger in
g:6b8b959675a3e14cfdd2145bd62
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100516
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104119
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104134
--- Comment #9 from Martin Sebor ---
The code uses the M_ macro:
pp_printf (pp, M_(""), variety);
on my machine it expands into:
pp_printf (pp, ((cxx_pp)->translate_identifiers ? gettext ("") :
("")), variety);
and GCC doesn't warn most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104135
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104134
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #20 from Martin Sebor ---
This warning, like all others, is meant to help find common bugs in ordinary
code. It shouldn't be expected to reflect implementation-defined behavior or
to be free of false positives. Tricky code that tri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #17 from Martin Sebor ---
Having spent some time trying to understand the function I think the following
simplification should capture its intent. It compiles without warnings at all
levels:
void *xrealloc (void *ptr, size_t size)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #14 from Martin Sebor ---
Removing the test for !size from the first conditional avoids the warning. I
don't fully understand what the code tries to do but the following avoids it at
-O2 (only):
void *xrealloc (void *ptr, int size)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #13 from Martin Sebor ---
I confused things (including myself) yesterday, sorry.
Let me try again, with just the -O2 behavior for the test case in comment #2:
void *xrealloc (void *ptr, int size)
{
void *ret = __builtin_realloc (
gnu.org |msebor at gcc dot
gnu.org
--- Comment #3 from Martin Sebor ---
Let me try to handle this for GCC 12.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104119
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Summary|Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96367
Martin Sebor changed:
What|Removed |Added
Known to fail|11.0|11.2.0, 12.0
--- Comment #2 from Martin S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93518
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2021-12-23 00:00:00 |2022-1-19
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89161
Martin Sebor changed:
What|Removed |Added
Known to fail|10.0|10.3.0, 11.2.0, 12.0
Last reconfirmed|2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104076
--- Comment #3 from Martin Sebor ---
Looking at the IL before r12-6694 I'm not sure I see what could be done to keep
the warning from triggering but maybe someone has an idea for a solution I'm
not seeing, in case this comes back with a differen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104103
--- Comment #3 from Martin Sebor ---
(In reply to seurer from comment #2)
The warning for gcc/testsuite/gcc.dg/torture/pr57147-2.c looks correct. The
g_return_jmp_buf variable has zero size but it's being passed to a function
declared to take
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104076
--- Comment #1 from Martin Sebor ---
This instance of the warning has disappeared with r12-6694.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #9 from Martin Sebor ---
My mistake, a PHI is an OR of its operands, not an AND. With that, the IL
doesn't rule out that the subsequent realloc() call isn't made with the
argument to a prior successful realloc(). So for the more in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
Martin Sebor changed:
What|Removed |Added
Component|tree-optimization |middle-end
--- Comment #7 from Martin Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
Martin Sebor changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104077
Bug 104077 depends on bug 104082, which changed state.
Bug 104082 Summary: Wdangling-pointer: 2 * false positive ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104082
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104082
Martin Sebor changed:
What|Removed |Added
Resolution|--- |INVALID
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
--- Comment #17 from Martin Sebor ---
Jaosn: this is how all middle-end warnings have always behaved. They trigger
on invalid statements present in the IL. A statement is considered invalid
when any of its operands is out of bounds or in some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104077
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2022-01-17
Alias|
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
This meta-bug tracks false positives and negatives in the middle-end
-Wdangling-pointer, new in GCC 12.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104076
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
As reported in
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588620.html, the new
-Wdangling-pointer issues a false positive for the following test case:
$ cat t.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
This meta-bug tracks false positives and negatives in the middle-end
-Wuse-after-free, new in GCC 12 (unrelated to -Wanalyzer-use-after-free).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #4 from Martin Sebor ---
Actually, this is already supposed to be handled but the code is not effective
due to a typo. This fixes it:
diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
index f639807a78a..f95
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84544
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974
--- Comment #18 from Martin Sebor ---
This detection is partially implemented in GCC 12 by the -Wdnagling-pointer:
$ cat pr49974.C && gcc -O -S -Wall pr49974.C
struct X { };
inline const X& f(const X& r) { return r; }
const X& g()
{
X x;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90905
--- Comment #9 from Martin Sebor ---
This still isn't diagnosed by GCC 12 even with its -Wuse-after-free and
-Wdangling-pointer.
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Target Milestone|--- |12.0
--- Comment #4 from Martin Sebor ---
Implemented in GCC 12 (r12-6605) as -Wuse-after-free.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80532
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63272
Martin Sebor changed:
What|Removed |Added
Target Milestone|--- |12.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104038
Martin Sebor changed:
What|Removed |Added
Summary|ranger infinite loop on a |ranger infinite loop on a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104038
--- Comment #4 from Martin Sebor ---
The problem is reproducible with -O1 and above. To confirm it's not infinite
recursion I let the process run for about an hour before killing it. Memory
consumption seems to slowly but steadily increase as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104038
--- Comment #3 from Martin Sebor ---
The basic block being analyzed is bb 2 in clang::clangd::stdlib::initialize().
What's unusual about it is that it's a sequence of 2464 assignments like so:
:
SymCount_21 = 0;
SymCount_22 = SymCount_21 + 1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104038
--- Comment #2 from Martin Sebor ---
Created attachment 52198
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52198&action=edit
Unreduced test case.
The attached translation unit reproduces the infinite loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104038
--- Comment #1 from Martin Sebor ---
Created attachment 52197
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52197&action=edit
Patch needed to trigger the infinite loop.
When the attached patch is applied the infinite loop can be triggere
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
I'm debugging what looks like an infinite loop deep in Ranger. Interrupting
with SIGABRT the cc1plus process while under GDB produces the backtrace below.
Retu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 101475, which changed state.
Bug 101475 Summary: missing -Wstringop-overflow storing a compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101475
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101475
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104012
--- Comment #6 from Martin Sebor ---
To expand a bit on the fuzziness at level 1. The logic is documented under the
-Wformat-overflow warning like so:
Numeric arguments that are known to be bounded to a subrange of their type,
or string argu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741
Bug 85741 depends on bug 104012, which changed state.
Bug 104012 Summary: [12 regression] -Wformat-truncation warnings not taking
previous length check into account
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104012
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104012
Martin Sebor changed:
What|Removed |Added
Resolution|--- |INVALID
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104017
--- Comment #1 from Martin Sebor ---
The warning triggers for the clobber statement in bb 43 below. _236 is assumed
to point to the beginning of the block of 512 bytes allocated by new, so
subtracting a positive integer from it or adding one in
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
I got the following report in my private mail. I file it here for reference
(and my analysis). Although the warning isn&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104012
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
||msebor at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=100861
Summary|Incorrect error generated |-Wismatched-new-delete due
|by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81453
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Martin Sebor -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
--- Comment #14 from Martin Sebor ---
Created attachment 52156
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52156&action=edit
Updated patch.
The attached patch is an updated version that fixes a few ICEs. It's not in
the archives becaus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103945
--- Comment #5 from Martin Sebor ---
(The patch review was never finished.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103945
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
--- Comment #13 from Martin Sebor ---
The patch submitted (but not approved) for GCC 11:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558775.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103940
--- Comment #2 from Martin Sebor ---
It makes sense to me, David.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103835
--- Comment #5 from Martin Sebor ---
It's the same cause. When the -Wformat-overflow and -truncation warnings are
unable to compute the exact length of a string argument to a directive like %s
they use the size of the array the string is stored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758
--- Comment #10 from Martin Sebor ---
The diagnostic kinds in the call:
warning_at (loc, OPT_Wpragmas,
"missing [error|warning|ignored|push|pop|ignored_attributes]"
" after %<#pragma GCC diagnostic%>");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103835
Martin Sebor changed:
What|Removed |Added
Summary|Bogus sprintf warnings |bogus sprintf warnings due
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103858
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741
Bug 85741 depends on bug 92943, which changed state.
Bug 92943 Summary: missing -Wformat-overflow with an allocated buffer with
non-constant size in known range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92943
What|Removed
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Status|NEW |RESOLVED
--- Comment #2 from Martin Sebor ---
Fixed by r11-5622 (AKA PR middle-end/97373).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103372
Martin Sebor changed:
What|Removed |Added
Known to fail||10.2.0, 11.2.0, 4.9.4,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103372
Bug 103372 depends on bug 99612, which changed state.
Bug 99612 Summary: Remove "#pragma GCC system_header" from atomic file to warn
on incorrect memory order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99612
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99612
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103907
Martin Sebor changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
I see a large number of C++ tests fail on x86_64-linux with
--target_board=unix/-m32 (but not with -m64). I don't recall having those
failures before wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84573
Martin Sebor changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Martin Sebor ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 102944, which changed state.
Bug 102944 Summary: Many gcc.dg/Wstringop-overflow-*.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102944
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102944
Martin Sebor changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
201 - 300 of 2456 matches
Mail list logo
