https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98512
Martin Sebor changed:
What|Removed |Added
Known to work||12.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 98871, which changed state.
Bug 98871 Summary: Cannot silence -Wmaybe-uninitialized at declaration site
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98871
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98871
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 102969, which changed state.
Bug 102969 Summary: [12 regression] g++.dg/warn/Wstringop-overflow-4.C fails
after r12-4726
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102969
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102969
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
I see the following failure in an x86_64-linux build with today's top of trunk:
Executing on host: /build/gcc-master/gcc/xgcc -B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Priority: P3
Component: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
A recent regression test run shows FAILs in a couple of JIT example programs,
both due to -Wformat-overflow errors:
/build/gcc-master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92879
--- Comment #12 from Martin Sebor ---
The test fails everywhere. It regressed with r12-5107 (see pr102690). The
solution was to xfail it (to your point in pr101674).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103173
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
||2021-11-10
Ever confirmed|0 |1
CC||msebor at gcc dot gnu.org
--- Comment #2 from Martin Sebor ---
Historically, flow-dependent warnings in GCC have relied on optimization. Some
work without it and just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103161
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103161
--- Comment #9 from Martin Sebor ---
Aaah, never mind. The test depends on the unspecified order of argument
evaluation. Doh!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103161
--- Comment #7 from Martin Sebor ---
I bet you can't see the failures because they depend on fixes in a patch that
hasn't been committed yet:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583735.html
But I wonder if there actually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103161
Martin Sebor changed:
What|Removed |Added
Component|tree-optimization |testsuite
--- Comment #5 from Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101917
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|fortran
||a/show_bug.cgi?id=102831
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
--- Comment #3 from Martin Sebor ---
Confirmed. It's a failure in what looks like a paranoia
||patch
CC||msebor at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #4 from Martin Sebor ---
Patch: https
||msebor at gcc dot gnu.org
Target Milestone|--- |11.4
Resolution|--- |FIXED
--- Comment #3 from Martin Sebor ---
This is accepted by GCC 12 in the default C++ mode. It looks like it's been
accepted since g
|--- |12.0
Status|NEW |RESOLVED
CC||msebor at gcc dot gnu.org
Keywords||rejects-valid
Known to fail||10.2.0, 11.2.0, 4.9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103145
Martin Sebor changed:
What|Removed |Added
Summary|False positive of |[11 Regression] bogus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103145
Martin Sebor changed:
What|Removed |Added
Known to work||10.3.0, 12.0
Blocks|
||msebor at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Known to fail||11.2.0, 12.0
Last reconfirmed||2021-11-09
--- Comment #1 from Martin Sebor
||2021-11-09
CC||msebor at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Summary|False positive |[10.11.12 Regression] Many
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103143
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102831
--- Comment #7 from Martin Sebor ---
(In reply to Peter Bergner from comment #6)
If it's reliably reproducible (ideally with a cross), can you attach a
translation unit and the options to use to reproduce it with?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102690
--- Comment #5 from Martin Sebor ---
It was backported here: g:19dcea67ac40cfdeb396fa264ebbe04fbe61fdc0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #15 from Martin Sebor ---
The call is made from the strlen pass which still does apparently use EVRP. I
believe Aldy's been moving it away from it (some of his changes are still
pending) as have I, so things are still in flux. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101397
Martin Sebor changed:
What|Removed |Added
Depends on||103143
--- Comment #8 from Martin Sebor
||ice-on-valid-code
Last reconfirmed||2021-11-09
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Ever confirmed|0 |1
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
As mentioned in bug 101397 comment #7, the following test cases causes infinite
recursion (and ultimately an ICE) in pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #13 from Martin Sebor ---
Here's a reduced test case that reproduces the problem with an x86_64-linux GCC
in ILP32 mode:
$ cat pr103121.C && gcc -O2 -S -Wall -m32 pr103121.C
typedef typeof (sizeof 0) size_t;
struct tree_node {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #12 from Martin Sebor ---
Okay, here's my question: when I call range_of_expr (vr, _4, stmt) with stmt
being 'grp_name_37 = __builtin_alloca (_4)' in BB 4, should I not expect the
result to be either VR_VARYING or [0, +INF]?
What I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #10 from Martin Sebor ---
Sorry, I've been having trouble with GDB and so I'm running two GDB sessions
and I have been mixing output from both of them. I see the warning for the
store to *_23 in BB 13, not for BB 12. Here's a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #8 from Martin Sebor ---
The [1, 1] range comes from a call to qry->range_of_expr (vr, exp, stmt) in in
get_size_range() in pointer-query.cc:
(gdb) p debug(gimple_bb(stmt))
[local count: 118111600]:
_4 = _1 + 1;
grp_name_37 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
Martin Sebor changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
Martin Sebor changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102831
--- Comment #4 from Martin Sebor ---
I have been testing the following changes to deal with other location and
warning related problems. They might be worth giving a try to see if they help
with this issue as well.
diff --git
|RESOLVED
CC||msebor at gcc dot gnu.org
--- Comment #2 from Martin Sebor ---
The warning corresponds to the call below where the RANGE shows what it's based
on:
;; basic block 10, loop depth 1, count 237404316 (estimated locally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967
--- Comment #7 from Martin Sebor ---
Both for the purposes of the warning (which can be more restrictive than what
the language considers valid), and in the C language, the semantics of the ->
expression depend on the first operand designating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967
--- Comment #4 from Martin Sebor ---
The expression pa->c is only valid if pa points to a valid object.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103056
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103036
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Blocks|
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The test case below shows that suppressing -Wuninitialized by #pragma GCC
diagnostic doesn't work the same
||msebor at gcc dot gnu.org
Keywords||patch
--- Comment #5 from Martin Sebor ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583045.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102996
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102960
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=90041
--- Comment #7 from Martin Sebor ---
As Jakub says in comment #2, this problem is not in a diagnostic format string
that the -Wformat checker sees.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93836
Martin Sebor changed:
What|Removed |Added
CC||mliska at suse dot cz
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93836
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
||88443
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
dress for a
|comparison will always |subexpression of a ternary
|evaluate as 'true'" |expression
CC| |msebor at gcc dot gnu.org
--- Comment #1 from Martin Sebor ---
The warning is intended: it points out that the seco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102965
Martin Sebor changed:
What|Removed |Added
Keywords||accepts-invalid
See Also|
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
In 7.17.1 Introduction to atomics, the C standard specifies that:
-5- In the following synopses:
— An A refers to an atomic type.
— A C refers to its
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102964
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2021-10-27
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91992
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102904
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102960
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
Bug 84774 depends on bug 102919, which changed state.
Bug 102919 Summary: spurious -Wrestrict warning for sprintf into the same
member array as argument plus offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102919
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102919
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 102453, which changed state.
Bug 102453 Summary: buffer overflow by atomic built-ins not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102453
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102453
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102958
--- Comment #1 from Martin Sebor ---
Something similar afflicts
libstdc++-v3/testsuite/21_strings/basic_string/capacity/1.cc but that test is
too contrived to matter in practice.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The two functions below are equivalent and would ideally both result in
optimally efficient code, but as the dump shows
ty: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
This is to make a record of a problem I recently ran into with GCC 12 and that
apparently others have as well. As disc
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC fails to fold the MIN_EXPR below to the lower address. The test case
affects C because the C front end emits
|1
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Keywords||diagnostic
Last reconfirmed||2021-10-25
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC diagnoses the first invalid call to free() below but fails to diagnose the
second. The problem is due to the warning using Object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102238
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102919
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Target Milestone|---
|1
Blocks||84774
Last reconfirmed||2021-10-24
Keywords||diagnostic
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Referenced Bugs
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The write below by sprintf into p->a cannot overlap with the read from p->a + 2
b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867
Martin Sebor changed:
What|Removed |Added
Summary|[12 Regression] Waddress|[12 Regression] -Waddress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 81981, which changed state.
Bug 81981 Summary: [8 Regression] -fsanitize=undefined makes a
-Wmaybe-uninitialized warning disappear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81981
What|Removed
||10.3.0, 11.2.0, 8.5.0,
||9.4.0
Keywords||xfail
Last reconfirmed|2017-08-25 00:00:00 |2021-10-22
CC||msebor at gcc dot gnu.org
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102887
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Last reconfirmed|
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
As noted here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582316.html
in a -Wuninitialized warning for the use of a variable in the expansion of a
macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867
Martin Sebor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC warns for less than comparisons of unsigned integers to zero but it fails
to do the same for unsigned bit-fields (likely because they promote
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
G++ warns when assigning to a bit-field a value that cannot be represented in
the object but GCC does not.
$ cat x.c && /build/gcc-master/gcc/xgcc -B /build/gcc-master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102828
Martin Sebor changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102810
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Ever
|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
--- Comment #3 from Martin Sebor ---
The code is certainly undefined but (appallingly), it's syntactically valid C.
The correspondingly hideous C++ version is also accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102744
Martin Sebor changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102733
--- Comment #3 from Martin Sebor ---
A couple of data points: I see the same behavior for any constant address (not
just null). Clang 12 behaves the same as GCC, but Clang 13 emits both stores,
suggesting they fixed it as a bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 102630, which changed state.
Bug 102630 Summary: [12 Regression] Spurious -Warray-bounds with named address
space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
While testing r12-4376 I noticed that when a fs:0 store is followed by one to
gs:0 the former is not emitted, otherwise when each is done on its own each is
also emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102731
Martin Sebor changed:
What|Removed |Added
Blocks||56456, 88443
Keywords|
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The test case below shows that GCC doesn't handle null pointer dereferences
consistently or as helpfully as it could or should. Of the three equivalent
functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99580
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2021-03-14 00:00:00 |2021-10-13
Summary|False
|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||msebor at gcc dot gnu.org
--- Comment #1 from Martin Sebor ---
Confirmed with the test case below:
$ cat pr102726.C && gcc -S -Wall pr102726.C
void f (bool);
enum
|1
Status|UNCONFIRMED |NEW
CC||msebor at gcc dot gnu.org
--- Comment #1 from Martin Sebor ---
Confirmed, also reported on x86_64 and i686:
https://gcc.gnu.org/pipermail/gcc-testresults/2021-October/727873
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
Martin Sebor changed:
What|Removed |Added
Severity|normal |enhancement
Component|c
|1
Status|UNCONFIRMED |NEW
CC||msebor at gcc dot gnu.org,
||siddhesh at redhat dot com
--- Comment #4 from Martin Sebor ---
I'm not sure how feasible
rmal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
This is to make a record of a bug in GCC's garbage collection machinery. With
the following patch I get the errors below. g
||msebor at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Summary|[Diagnostics] uninitialized |[12 Regression] wrong
|warning missing after O2|location in -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102706
Martin Sebor changed:
What|Removed |Added
CC||crazylht at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102697
Martin Sebor changed:
What|Removed |Added
Summary|[Diagnostics] overflow |[12 Regression] overflow
401 - 500 of 8151 matches
Mail list logo
