https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407
Steinar H. Gunderson changed:
What|Removed |Added
CC||steinar+gcc at gunderson dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407
--- Comment #22 from Steinar H. Gunderson ---
C.67 would seem only to apply to non-abstract base classes, no? The code
doesn't compile if B has pure virtual member functions. (Well, it doesn't
compile as-is already, but change (d) to (*d) and it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407
--- Comment #19 from Steinar H. Gunderson ---
Thanks for confirming; so GCC is absolutely right here, it's the standard that
makes a choice with surprising ramifications (to me, at least). I wonder if I
should try to ask someone in the standards
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: steinar+gcc at gunderson dot no
Target Milestone: ---
The other day, I had to debug (production!) code that essentially did this:
void func(int x) {
switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038
--- Comment #4 from Steinar H. Gunderson ---
Oh, it exists? Yes, if so, please count this as a request for enabling on
-Wextra.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: steinar+gcc at gunderson dot no
Target Milestone: ---
Hi,
The following program gives a warning with -Wall:
#include
std::enable_if
func() {}
klump:~> g++-8 -O2 -std=gnu++14 -Wall -c test.cpp
test.cpp: In function ‘
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86642
Steinar H. Gunderson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86642
--- Comment #4 from Steinar H. Gunderson ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Steinar H. Gunderson from comment #0)
> > Same issue with 4.9, so no regression. Clang has the same issue.
>
> That should have been your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86214
--- Comment #4 from Steinar H. Gunderson ---
New test case added. It's quite a bit larger than the old one, but has no
-Wreturn-type warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86214
Steinar H. Gunderson changed:
What|Removed |Added
Attachment #44296|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86214
--- Comment #7 from Steinar H. Gunderson ---
Created attachment 44351
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44351=edit
Unreduced test case
There; unreduced, from public MySQL. This is preprocessed with GCC 7, and
compiles both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86214
--- Comment #6 from Steinar H. Gunderson ---
I wouldn't be surprised if everything is really over-reduced, and that GCC 7
just happens not to hit this by luck.
I'll be making a checkout of the public git repository and try to reproduce
there,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038
--- Comment #16 from Steinar H. Gunderson ---
Since you're asking (presumably rhethorically): I would certainly recommend
that this code be changed, yes, and I don't find the author's intent obvious at
all. The fix that comes to mind is to scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038
--- Comment #11 from Steinar H. Gunderson ---
It is also not legal (side effects or not) when compiling as C++, which is one
of the reasons for having this warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038
--- Comment #13 from Steinar H. Gunderson ---
That could be (I disagree, but that's another debate), but the question was
whether allowing this case would improve the warning or not. If you change it
to allowing such a case, you also make
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: steinar+gcc at gunderson dot no
Target Milestone: ---
Created attachment 44942
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44942=edit
Redu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407
--- Comment #26 from Steinar H. Gunderson ---
That blog post seems to advocate using std::unique_ptr for pretty much
everything, which unfortunately doesn't always work. See e.g. slide 8 of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86214
--- Comment #19 from Steinar H. Gunderson ---
Thanks for fixing. IIRC we just added a noinline attribute somewhere in the
code, so we already have a workaround.
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: steinar+gcc at gunderson dot no
Target Milestone: ---
Hi,
Since recent GCC 9 snapshots, this code now fails:
template
void foo() {
char row[] = {"test"};
}
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #14 from Steinar H. Gunderson ---
I tested with a GCC snapshot (at r267505). I can now build all mysqld with LTO
and get exactly one LTO warning, and it's a true positive (two Bison parsers
that we haven't managed to untangle yet).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #16 from Steinar H. Gunderson ---
Yes, I'm fine with closing this bug; the spurious cases are gone, and the
traces seem to be genuinely helpful now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87300
--- Comment #4 from Steinar H. Gunderson ---
Wait, can it elide the move even if it's a conversion? How could that work in
the general case?
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: steinar+gcc at gunderson dot no
Target Milestone: ---
Hi,
-Wredundant-move sometimes gives false positives in C++11 mode -- the std::move
calls are simply not redundant. Case in point:
atum17:~> cat test.cc
#incl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87300
--- Comment #2 from Steinar H. Gunderson ---
Hm, am I misunderstanding it? It said “Status: C++14”. Even so, does it apply
to C++11?
++
Assignee: unassigned at gcc dot gnu.org
Reporter: steinar+gcc at gunderson dot no
Target Milestone: ---
Hi,
The following is a reduced test case from MySQL:
char func(long j)
{
char h[65536];
char *copy = h + (j & 0x3fffL);
return *(copy - 6);
}
G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89720
--- Comment #3 from Steinar H. Gunderson ---
Are there also any plans to make the warning easier to trace?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89720
--- Comment #7 from Steinar H. Gunderson ---
The inlining context, yes. Thanks for pointing out the relevant bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
--- Comment #9 from Steinar H. Gunderson ---
Putting this at the start of mem_strdupl() suppresses the warning:
if (len + 1 == 0) __builtin_unreachable();
This seemingly also does:
if (static_cast(len) < 0) __builtin_unreachable();
So
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: steinar+gcc at gunderson dot no
Target Milestone: ---
Hi,
We saw this coming only with GCC 10 (probably different inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
--- Comment #6 from Steinar H. Gunderson ---
So basically GCC is worried that I might be calling allocate() with -1 bytes,
and gives a warning?
last_slash presumably has to be >= path, given that it comes out of strrchr().
But maybe GCC won't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
--- Comment #1 from Steinar H. Gunderson ---
Created attachment 46689
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46689=edit
Unreduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
--- Comment #3 from Steinar H. Gunderson ---
Yes, the reduced one is awkward. Thus the unreduced one :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
--- Comment #8 from Steinar H. Gunderson ---
But all of those conditions include last_slash > path.
I tried adding this just before the mem_strdupl() call:
if (last_slash < path) {
ib::fatal() << "Logic error.";
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
--- Comment #22 from Steinar H. Gunderson ---
Yes; I had a project recently where I won 15% overall performance (!) by using
an asm statement with bsf instead of ffsll(). (This skipped both the sign
extension and the check for zero; my argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94956
--- Comment #1 from Steinar H. Gunderson ---
Sorry, truncated the assembler. GCC's is:
atum17:~> objdump --disassemble test.o
test.o: file format elf64-x86-64
Disassembly of section .text:
:
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: steinar+gcc at gunderson dot no
Target Milestone: ---
Hi,
Given GCC 10 x86-64, and this code:
#include
#include
int foo(uint32_t x) {
if (x == 0) __builtin_unreachable();
return ffs(x) - 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94956
--- Comment #6 from Steinar H. Gunderson ---
Oh nice! I'll be sure to benchmark when I can get my hands on appropriate
binaries (I typically use gcc-snapshot from Debian).
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: steinar+gcc at gunderson dot no
Target Milestone: ---
The following code is reduced from a real interpreter:
extern void (*a[])();
int d, e, h, l;
typedef struct {
char ab;
} f;
f g;
short i();
short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94956
--- Comment #7 from Steinar H. Gunderson ---
To wrap this up, confirming that GCC 11 does well on my benchmark:
BM_Chain2054529 iterations 18781 ns/iter GCC 10, asm bsfq
BM_Chain2044584 iterations 22509
Assignee: unassigned at gcc dot gnu.org
Reporter: steinar+gcc at gunderson dot no
Target Milestone: ---
The code after reduction is:
struct {
int b[6];
} c;
unsigned char d;
void e() {
unsigned char a = d >> 4, f = d & 15;
c.b[a] = c.b[f];
}
with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101200
--- Comment #6 from Steinar H. Gunderson ---
You're right, I don't know why the shrq happened. When I run now, I get shrb.
Doesn't matter for the bug, though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101139
--- Comment #4 from Steinar H. Gunderson ---
Yes, the integer promotion actually costs some performance. It happens on both
x86 and Arm. Should I file that as a separate bug?
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: steinar+gcc at gunderson dot no
Target Milestone: ---
Found while minimizing another regression:
gcc version 12.0.0 20210918 (experimental) [master r12-3644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103273
Steinar H. Gunderson changed:
What|Removed |Added
Resolution|--- |INVALID
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: steinar+gcc at gunderson dot no
Target Milestone: ---
This is a bit of a long shot, but I'll file it anyway :-)
I have this function in a hot path (o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103071
--- Comment #2 from Steinar H. Gunderson ---
EitherIsSubset() in the example calls foo or bar (but with a redundant test
that I can't get easily rid of). I agree that if you just return 0/1, the
cmp+sete+or variant is probably as good, but
46 matches
Mail list logo
