https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92323
Martin Sebor changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 92323, which changed state.
Bug 92323 Summary: bogus -Warray-bounds after unrolling despite
__builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92323
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84050
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2018-01-26 00:00:00 |2020-1-30
Known to fail|
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Of the three calls with invalid arguments in the test case below only the last
one is diagnosed.
The negative offset isn&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93514
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93514
--- Comment #3 from Martin Sebor ---
There is no tail padding at ax2.a + 3, it's just past the end of the the
four-byte object because ax2.a is at offset 1.
-Warray-bounds takes tail padding into consideration by calling
component_ref_size(). T
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The warning below is incorrect because (assuming a is a nul-terminated string)
the length of s1 must be at most 1 and the
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
In the test case below only the sprintf call in first function is diagnosed for
the potential overflow, not the
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
This was reported in RHBZ #1796688 (and previously for memcpy in bug 83456).
The warning is obviously incorrect here:
#include
static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93519
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
In the following test case only the overlapping calls are diagnosed that pass
the source argument as the destination are diagnosed; none of
at gcc dot gnu.org |msebor at gcc dot
gnu.org
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The inequality below is trivially false but since GCC 4.6 the middle-end fails
to fold it into a constant (it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93538
--- Comment #1 from Martin Sebor ---
(I noticed this while testing my fix for bug 93519.)
Here's a (strictly undefined) test case involving memcpy where the lack of
folding it prevents the call from being eliminated (it is ultimately eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93538
--- Comment #2 from Martin Sebor ---
A better (well-defined) test case involves memmove:
$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout -o/dev/stdout
a.c
struct A { char a[3]; };
void f (struct A *a)
{
void *p = a;
void *q
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
While experimenting with the test case from pr3538 I noticed that GCC doesn't
take full advantage of the fact that func
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC lowers calls to strpcpy whose result isn't used to strcpy, presumably
because the latter tends to be more efficient. With pr90263 resolved, GCC also
ex
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The two functions below create the same string but f1() is micro-optimized to
avoid copying the terminating nul in "1234" before immediately appen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93519
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from Martin Sebor -
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC should fold strstr(a, b) to a when a and b point to the same string, the
same way Clang does.
$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout a.c
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #2 from Martin Sebor ---
Below is a simplified C test case. The warning is justified and works
correctly, but the index and the type it prints might be a little confusing.
The index corresponds to the MEM_REF offset which is set to
|UNCONFIRMED |NEW
Last reconfirmed||2020-02-04
CC||msebor at gcc dot gnu.org
Component|c |middle-end
Summary|internal compiler error:|[10 Regression] internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93576
--- Comment #5 from Martin Sebor ---
The full compiler output is useful. Some of us use it to quickly see what part
of the compiler is affected. It also helps make sure we're reproducing the
same problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #8 from Martin Sebor ---
We would need to see the original code (the translation unit) to tell for sure
why the warning is only issued on some targets and not on others, but the most
likely answer is that the code results in different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #11 from Martin Sebor ---
-mtune=z13 seems to enable more inlining so many of the past-the-end references
to the tempGrab local variable end up inlined into the bodies of the functions
that define them.
For example:
PassivGrab.c: In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84275
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
Martin Sebor changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #13 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93616
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89288
Martin Sebor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
-Wformat-overflow diagnoses sprintf calls that might overflow the destination
based solely on the size of the array where the string
|UNCONFIRMED |NEW
Last reconfirmed||2020-02-09
CC||msebor at gcc dot gnu.org
Component|other |middle-end
Summary|-Wreturn-local-addr July|[10 Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90556
Bug 90556 depends on bug 81811, which changed state.
Bug 81811 Summary: missing -Wreturn-local-addr returning strcpy result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81811
What|Removed |Added
-optimization |middle-end
Resolution|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Target Milestone|--- |10.0
--- Comment #5 from Martin Sebor ---
Fixed for GCC 10 (most likely by r273261
|UNCONFIRMED |NEW
Last reconfirmed||2020-02-09
CC||msebor at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93640
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
|UNCONFIRMED |RESOLVED
CC||msebor at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Martin Sebor ---
The warning is intentional. The expected use of the strncat function is to
limit the output to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644
--- Comment #4 from Martin Sebor ---
pr90735 suggests using the location of the closing curly brace of the function
instead. Another alternative might be to use the location associated with the
note.
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The -Wstringop-overflow warning in the code below is expected because a call to
strncat with a bound equal to the
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Ever confirmed|0 |1
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781
[Bug 88781] [meta-bug] bogus/missing -Wstringop-truncation warnings
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
-Wstring-compare diagnoses equality expressions involving calls to strcmp and
strncmp that evaluate to constant s based on the size of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93640
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93653
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Severity|normal
: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
In addition to pr93653, the -Wstring-compare warning (new in GCC 10) could also
diagnose strncmp calls where the bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93646
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #1 from Martin Sebor -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82456
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2019-01-14 00:00:00 |2020-2-10
Known to fail|9.0
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC 10 diagnoses the call to strcmp below because it attempts to read past the
end of the unterminated array a3 but not the call to
||2020-02-10
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Martin Sebor ---
Bisection points to r273194:
2019-07-08 Richard Biener
PR tree-optimization/83518
* tree
||i386-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-02-10
CC||msebor at gcc dot gnu.org
Component|c |target
Ever confirmed|0
||2020-02-10
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
Please include all details relevant to your report, including a description of
the problem you see and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93663
Martin Sebor changed:
What|Removed |Added
Component|target |middle-end
--- Comment #2 from Martin Seb
|UNCONFIRMED |NEW
Last reconfirmed||2020-02-11
CC||msebor at gcc dot gnu.org
Component|c |tree-optimization
Target Milestone|--- |10.0
Ever
at gcc dot gnu.org |msebor at gcc dot
gnu.org
--- Comment #2 from Martin Sebor ---
It looks like the new code simply assumes the LHS is non-zero when it need not
be.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90938
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #12 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93683
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Martin Sebor -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93683
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93697
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #4
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC diagnoses some suspicious memset calls whose last two arguments look like
they may have been transposed by -Wmemset-transposed-args
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
With one exception, the warnings for the invalid array initializers are not
associated with their location: they all point to the closing
||2020-2-12
CC||msebor at gcc dot gnu.org
Resolution|--- |DUPLICATE
Known to fail||10.0, 7.3.0, 8.3.0, 9.2.0
--- Comment #1 from Martin Sebor ---
Confirmed. These -Warray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86650
Martin Sebor changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #6 fr
||2020-02-12
CC||msebor at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=84542
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781
Bug 88781 depends on bug 93646, which changed state.
Bug 93646 Summary: confusing -Wstringop-truncation on strncat where
-Wstringop-overflow is expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93646
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93646
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
For an implementation of a swap function like this:
template
void swap (std::pair &x)
{
T t = x.first;
x.first = x.second;
x.second = t;
}
GCC
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC emits what's likely more efficient code for the insertion of elements into
the middle of small arrays by copying parts of the array into a temporary
b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93737
Martin Sebor changed:
What|Removed |Added
Keywords||missed-optimization
See Also|
||2020-02-13
CC||msebor at gcc dot gnu.org
Known to work||7.3.0
Summary|internal compiler error: in |[8/9/10 Regression]
|force_constant_size, at |internal compiler error: in
||2020-02-13
CC||msebor at gcc dot gnu.org
Known to work||4.4.3
Summary|internal compiler error: q |[8/9/10 Regression]
|from h referenced in main |internal compiler error: q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93737
--- Comment #3 from Martin Sebor ---
I was thinking for small N, the middle-end could make it work by emitting
copies of the sequences using MEM_REFs, along these lines:
char _2[N - 2];
_2 = MEM [(char * {ref-all})&a + 1];
MEM [(char * {
|NEW |ASSIGNED
CC||msebor at gcc dot gnu.org
Known to work||4.4.3
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Summary|ICE: in get, at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92799
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #5 from Martin Sebor -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93745
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93745
Martin Sebor changed:
What|Removed |Added
Summary|Redundant store not |[8/9/10 Regression]
|el
||2020-02-16
CC||fxue at os dot
amperecomputing.com
||, msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Martin Sebor ---
Bisection points to r10
||2020-02-16
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||10.0, 4.1.3, 4.3.5, 4.4.7,
||4.8.5, 4.9.4, 5.4.0, 6.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58646
Martin Sebor changed:
What|Removed |Added
CC||akhilesh.k at samsung dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93730
Martin Sebor changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|NE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58646
Martin Sebor changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
Known to work|
at gcc dot gnu.org |msebor at gcc dot
gnu.org
Summary|[8/9/10 Regression] ICe in |[8/9/10 Regression] ICE on
|output_constructor_regular_ |a flexible array followed
|field, at varasm.c:5255 |by a member in an anonymous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93753
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93631
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93745
--- Comment #7 from Martin Sebor ---
That's why I asked "What language relies on this?"
But regardless of what language might have even looser rules than C/C++ in this
area, it would seem like a rather unfortunate design limitation for GCC not t
iority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
As noted in https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01016.html,
-Wredundant-tags is not useful for declarations in shared C/C++ headers that
cannot be
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: ---
While testing a fix for pr93801 I noticed that G++ rejects the last type
definition in the test case below. The code looks valid to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93809
Martin Sebor changed:
What|Removed |Added
Keywords||rejects-valid
Known to fail|
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The typedef below should be diagnosed by -Wmismatched-tags but isn't. Both
Clang and Visual C++ diagnose it as exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93810
Martin Sebor changed:
What|Removed |Added
Summary|missing -Wmismatched-tags |missing -Wmismatched-tags
++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The second typedef in the test case below is invalid for the same reason as the
first but only the first one is diagnosed and rejected. The second one is
silently accepted and
|ASSIGNED
Last reconfirmed||2020-02-19
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
Patch: https://gcc.gnu.org/ml/gcc-patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93730
--- Comment #7 from Martin Sebor ---
I think VLA initialization should be rejected in C++ just as it is in C.
The mangling wasn't specified the last time I checked so unless there has been
some informal consensus on how to do it changing it for
: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The following test case reduced from RHBZ #1800289 shows a
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Ever confirmed|0 |1
Known to fail||10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63989
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2014-11-20 00:00:00 |2020-2-19
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77889
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2016-10-07 00:00:00 |2020-2-19
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93829
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68531
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2016-07-11 00:00:00 |2020-2-20
Summary|incorrect co
901 - 1000 of 7511 matches
Mail list logo
