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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104232
Martin Sebor changed:
What|Removed |Added
Blocks||104075
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104232
Bug ID: 104232
Summary: spurious -Wuse-after-free after conditional free
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104216
Bug ID: 104216
Summary: -w overrides #pragma GCC diagnostic which overrides
-Werror
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104203
Martin Sebor changed:
What|Removed |Added
Summary|[12 Regressions] huge |[12 Regressions] huge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104215
Bug ID: 104215
Summary: bogus -Wuse-after-free=3 due to forwprop moving a
pointer test after realloc
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: n
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104213
Martin Sebor changed:
What|Removed |Added
Blocks||104075
CC|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104165
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
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 #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104134
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #2
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 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104119
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Summary|unexpected
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|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104077
Bug ID: 104077
Summary: bogus/missing -Wdangling-pointer
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104076
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104076
Bug ID: 104076
Summary: bogus -Wdangling-pointer on a conditional
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075
Bug ID: 104075
Summary: bogus/missing -Wuse-after-free
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
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
Assi
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90906
Martin Sebor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104038
Bug ID: 104038
Summary: ranger infinite loop on a PHI statement
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opt
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104017
Bug ID: 104017
Summary: unexpeted -Warray-bounds popping a fixed number of
std::deque elements
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104012
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103993
Martin Sebor changed:
What|Removed |Added
Blocks||100406
CC|
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 #4
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 #2
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92943
Martin Sebor changed:
What|Removed |Added
Target Milestone|--- |11.0
Resolution|---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103907
Bug ID: 103907
Summary: many C++ test failures with --target_board=unix/-m32
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
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 1401 matches
Mail list logo