[Bug c/110645] New: False positive -Warray-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110645 Bug ID: 110645 Summary: False positive -Warray-bounds warning Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: andres at anarazel dot de Target Milestone: --- Created attachment 55531 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55531&action=edit reproducer Hi, The attached minimized reproducer (from postgres code) triggers a clearly bogus -Warray-bounds warning, even with -Warray-bounds=1. $ gcc -O1 -Wall -Warray-bounds=1 -c -o /dev/null -c repro.i In function ‘formTextDatum’, inlined from ‘spgist_name_compress’ at /tmp/cvise2/repro.i:44:9: /tmp/cvise2/repro.i:35:17: warning: ‘memcpy’ forming offset [2, 254] is out of the bounds [0, 2] [-Warray-bounds] 35 | memcpy(att->data, src, srclen); | ^~~~ This is despite srclen being strlen(src), which gcc does know is <= 1. It seems that the known range of srclen is "widened" due to the if (srclen < 0xff), causing the warning. It is somewhat interesting that removing -Wall removes the spurious warning, despite -Warray-bounds=1. This triggers for gcc-11 - HEAD at 3b007164b3e, but not in gcc-10. I looked through quite a few bugs about spurious -Warray-bounds warnings to see if this is a duplicate - quite possible, but I didn't find a real match for this. Regards, Andres
[Bug c/110609] Bogus -Wmismatched-dealloc when allocator defined & used in same TU w/ -fPIC -fno-semantic-interposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110609 --- Comment #2 from Andres Freund --- (In reply to Andrew Pinski from comment #1) > Dup. > > *** This bug has been marked as a duplicate of bug 110546 *** Are they really the same? This bug happens at -O0 and requires -fPIC and -fno-semantic-interposition, whereas #110546 requires -O3? I don't know enough about gcc, so you probably are right...
[Bug c/110609] New: Bogus -Wmismatched-dealloc when allocator defined & used in same TU w/ -fPIC -fno-semantic-interposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110609
Bug ID: 110609
Summary: Bogus -Wmismatched-dealloc when allocator defined &
used in same TU w/ -fPIC -fno-semantic-interposition
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
Target Milestone: ---
Hi,
Whenever an allocator function annotated with attribute((malloc(freelike)) is
defined and used in the same translation unit and -fno-semantic-interposition
-fPIC are used, bogus mismatched alloc/free warnings ensue.
void somefree(int *);
__attribute__((__malloc__(somefree, 1)))
int *somealloc(void) {
return 0;
}
void other(void) {
int *v = somealloc();
somefree(v);
}
---
gcc -Wmismatched-dealloc -fno-semantic-interposition -fPIC -o a.out -c fd.c.i
fd.c.i: In function ‘other’:
fd.c.i:10:3: warning: ‘somefree’ called on pointer returned from a mismatched
allocation function [-Wmismatched-dealloc]
10 | somefree(v);
| ^~~
fd.c.i:9:12: note: returned from ‘somealloc.localalias’
9 | int *v = somealloc();
|^~~
This appears to happen with all versions supporting -Wmismatched-dealloc,
including today's git head at 3b007164b3e.
Regards,
Andres
[Bug c/107224] New: ICE: verify_cgraph_node failed with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107224 Bug ID: 107224 Summary: ICE: verify_cgraph_node failed with -Og Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: andres at anarazel dot de Target Milestone: --- Created attachment 53693 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53693&action=edit reproducer Hi, When building postgres with gcc 13 I get a lot of ICEs. I reproduced this on today's master (53955284c03) and reduced one of the failing files with cvise. $ ~/build/gcc-master/install/bin/gcc -Og -c gindatapage.i -o gindatapage.o [bunch of warnings due to cvise] > QI size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7f3b8de315e8 arg-types >> volatile nothrow public external built-in decl_6 QI :0:0 align:8 warn_if_not_align:0 built-in: BUILT_IN_NORMAL:BUILT_IN_TRAP context attributes chain chain chain >>>> chain > Instead of: unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7f3b8de215e8 precision:32 min max pointer_to_this > QI size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7f3b8de30930 pointer_to_this > addressable used public external decl_2 decl_5 QI gindatapage.i:3:5 align:8 warn_if_not_align:0 chain > ItemPointerSet/0 (ItemPointerSet) Type: function definition analyzed Visibility: semantic_interposition external public References: Referring: Function ItemPointerSet/0 is inline copy in dataBeginPlaceToPage_maxOldItem/1 Availability: available Function flags: body Called by: dataBeginPlaceToPage_maxOldItem/1 (inlined) Calls: __builtin_trap/3 (0 (precise),1.00 per call) during GIMPLE pass: einline gindatapage.i:6:3: internal compiler error: verify_cgraph_node failed 0xa35b90 cgraph_node::verify_node() /home/andres/src/gcc/gcc/cgraph.cc:3881 0xa25804 symtab_node::verify() /home/andres/src/gcc/gcc/symtab.cc:1360 0xf5b0da expand_call_inline /home/andres/src/gcc/gcc/tree-inline.cc:4912 0xf5dbd6 gimple_expand_calls_inline /home/andres/src/gcc/gcc/tree-inline.cc:5318 0xf5dbd6 optimize_inline_calls(tree_node*) /home/andres/src/gcc/gcc/tree-inline.cc:5490 0x1d277ed early_inliner(function*) /home/andres/src/gcc/gcc/ipa-inline.cc:3038
[Bug ipa/106809] New: [12 regression] large bison grammars compilation got a lot slower, mainly due to -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106809 Bug ID: 106809 Summary: [12 regression] large bison grammars compilation got a lot slower, mainly due to -Wuninitialized Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: andres at anarazel dot de CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 53529 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53529&action=edit preprocessed input file showing slowdown Hi, I noticed that building the .c output from bison got a lot slower in 12, compared to 11. $ gcc-12 --version gcc-12 (Debian 12.2.0-1) 12.2.0 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc-12 preproc.i -c -Wuninitialized real0m3.558s user0m3.475s sys 0m0.083s $ time gcc-11 preproc.i -c -Wuninitialized real0m1.232s user0m1.150s sys 0m0.082s This is a pretty egregious case, for saner grammars the performance difference is smaller. There's also a performance difference without -Wuninitialized, but it's much smaller (1.090s -> 1.314s) Looking at -ftime-report, there's a very clear difference in how much time is spent in "uninit var analysis" 11: uninit var analysis: 0.01 ( 1%) 0.00 ( 0%) 0.00 ( 0%)10k ( 0%) 12: uninit var analysis: 2.24 ( 63%) 0.00 ( 0%) 2.26 ( 55%) 393k ( 1%) Regards, andres
[Bug target/106590] x86-64 miscompilation starting with "i386: Improve ix86_expand_int_movcc" w/ mtune=skylake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106590 --- Comment #1 from Andres Freund --- Created attachment 53441 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53441&action=edit reproducer
[Bug target/106590] New: x86-64 miscompilation starting with "i386: Improve ix86_expand_int_movcc" w/ mtune=skylake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106590 Bug ID: 106590 Summary: x86-64 miscompilation starting with "i386: Improve ix86_expand_int_movcc" w/ mtune=skylake Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: andres at anarazel dot de Target Milestone: --- Hi, The attached reproducer shows a miscompilation I found building postgres. I've bisected postgres' failure to 1ceddd7497e, but it's of course possible it's just surfacing a prior issue. In my reproducer, and in postgres, the problem only occurs with -mtune=skylake or higher, but I'm not sure how related that actually is. $ /home/andres/build/gcc-master/install/bin/gcc --version gcc (GCC) 12.0.1 20220423 (experimental) Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc-11 --version gcc-11 (Debian 11.3.0-5) 11.3.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ /home/andres/build/gcc-master/install/bin/gcc -Wall -Wextra -O1 -mtune=skylake /tmp/test.i -o /tmp/test $ /tmp/test wrong results: procform->prorettype: 23, restype: 20 $ /home/andres/build/gcc-master/install/bin/gcc -Wall -Wextra -O1 -mtune=broadwell /tmp/test.i -o /tmp/test $ /tmp/test everything ok: procform->prorettype: 23, restype: 23 $ gcc-11 -Wall -Wextra -O1 -mtune=skylake /tmp/test.i -o /tmp/test $ /tmp/test everything ok: procform->prorettype: 23, restype: 23 I think it's pretty obvious that the code should never be able to result in restype == 20. Regards, Andres
[Bug middle-end/104986] New: [12 Regression] bogus writing 1 byte into a region of size 0 with -fwrapv and -O2 -fpeel-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986
Bug ID: 104986
Summary: [12 Regression] bogus writing 1 byte into a region of
size 0 with -fwrapv and -O2 -fpeel-loops
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
Target Milestone: ---
Hi,
recently started seeing bogus warnings using gcc 12 to build postgres. I
reduced the problem using cvise with some manual cleanups / improvements
afterwards - certainly doesn't quite make sense anymore, but afaics shows a
problem.
Originally I hit this with -O3, but found that -O2 -fpeel-loops is sufficient
to trigger the problem.
repro: https://godbolt.org/z/ejK9h6von
code:
struct inet_struct {
char family;
char ipaddr[16];
};
void
inetnot(struct inet_struct *dst1, struct inet_struct *dst2, struct inet_struct
*src) {
int nb = src->family ? 4 : 6;
char *psrc = src->ipaddr;
char *pdst = dst1 ? dst1->ipaddr : dst2->ipaddr;
while (nb-- > 0)
pdst[nb] = psrc[nb];
}
gcc-12 -fwrapv -O2 -fpeel-loops -c network2.i
network2.i: In function ‘inetnot’:
network2.i:12:14: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
12 | pdst[nb] = psrc[nb];
| ~^~
network2.i:3:8: note: at offset -1 into destination object ‘ipaddr’ of size 16
3 | char ipaddr[16];
|^~
network2.i:3:8: note: at offset -1 into destination object ‘ipaddr’ of size 16
which afaics is bogus, because the loop terminates before reaching offset -1,
the condition is > 0, not >= 0. So the post decrement can't lead to -1 being
reached.
version: gcc version 12.0.1 20220314 (experimental) [master
r12-7638-g823b3b79cd2] (Debian 12-20220313-1)
Regards,
Andres
[Bug tree-optimization/100442] Spurious -Wstringop-overread error with odd boundaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100442 --- Comment #4 from Andres Freund --- > Ending up with an excessive range isn't uncommon in code that freely converts > between signed and unsigned integers (e.g., by passing an int to a size_t > argument) and involves conditionals like those in tsCompareString(). GCC > must assume the signed integers may be negative and convert to very large > positive values. Changing tsCompareString() to take size_t arguments instead > of int avoids the warning: That true - and I agree that that code isn't great. But the warning message is quite confusing: A bound of "[18446744073709551612, 18446744073709551615]" doesn't sound right from the perspective a compiler user, rather than compiler author. Clearly the lower bound isn't actually 18446744073709551612.
[Bug tree-optimization/101481] New: -ftree-loop-distribute-patterns can slow down and increases size of code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101481
Bug ID: 101481
Summary: -ftree-loop-distribute-patterns can slow down and
increases size of code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
Target Milestone: ---
Created attachment 51168
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51168&action=edit
simplified example reproducing problem
Hi,
I found -ftree-loop-distribute-patterns to be far too aggressive in replacing
code, leading to increased code size and substantial slowdowns (12% in the
program I just hit this).
The code size increase & slowdown are partially caused by the function call
itself, and partially due to the spilling necessary to make that function call.
Worsened by the PLT call to memmove().
A very simplified example (also attached) is this:
typedef struct node
{
unsigned char chunks[4];
unsigned char count;
} node;
void
foo(node *a, unsigned char newchunk, unsigned char off)
{
if (a->count > 3)
__builtin_unreachable();
for (int i = a->count - 1; i >= off; i--)
a->chunks[i + 1] = a->chunks[i];
a->chunks[off] = newchunk;
}
which with `-O2 -fPIC` boils down to:
foo(node*, unsigned char, unsigned char):
pushq %r12
movl%edx, %r8d
movl%esi, %r12d
pushq %rbp
movq%rdi, %rbp
pushq %rbx
movzbl 4(%rdi), %ecx
movzbl %r8b, %ebx
leal-1(%rcx), %edx
cmpl%ebx, %edx
jl .L2
movl%ecx, %eax
movslq %edx, %rsi
subl%ebx, %ecx
subl$1, %ecx
movq%rsi, %rdx
subq%rcx, %rdx
leaq1(%rcx), %r8
leaq(%rdi,%rdx), %rsi
movzbl %al, %edi
movq%r8, %rdx
movq%rdi, %rax
subq%rcx, %rax
leaq0(%rbp,%rax), %rdi
callmemmove@PLT
.L2:
movb%r12b, 0(%rbp,%rbx)
popq%rbx
popq%rbp
popq%r12
ret
compare to `-O2 -fPIC -fno-tree-loop-distribute-patterns`
foo(node*, unsigned char, unsigned char):
movzbl 4(%rdi), %eax
movzbl %dl, %edx
subl$1, %eax
cmpl%edx, %eax
jl .L2
cltq
.L3:
movzbl (%rdi,%rax), %ecx
movb%cl, 1(%rdi,%rax)
subq$1, %rax
cmpl%eax, %edx
jle .L3
.L2:
movb%sil, (%rdi,%rdx)
ret
Which I think makes the problem apparent.
Regards,
Andres Freund
[Bug tree-optimization/100442] Spurious -Wstringop-overread error with odd boundaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100442 --- Comment #2 from Andres Freund --- Created attachment 50763 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50763&action=edit preprocessed reproducer Huh, sorry for that. I thought I had attached it. When I tried again now it failed due to the size limit - maybe I somehow managed to submit the bug despite that, but the size error caused the attachment to not be there silently? Or I just forgot to press a button or such...
[Bug c/100442] New: Spurious -Wstringop-overread error with odd boundaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100442 Bug ID: 100442 Summary: Spurious -Wstringop-overread error with odd boundaries Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: andres at anarazel dot de Target Milestone: --- Hi, When compiling one of postgres' source files with -O3 I see the following: gcc-11 -O3 -Wall -o /dev/null -c tsvector_op.i In function 'tsCompareString', inlined from 'tsCompareString' at /home/andres/src/postgresql/src/backend/utils/adt/tsvector_op.c:1147:1, inlined from 'tsvector_bsearch' at /home/andres/src/postgresql/src/backend/utils/adt/tsvector_op.c:410:9: /home/andres/src/postgresql/src/backend/utils/adt/tsvector_op.c:1164:23: warning: 'memcmp' specified bound [18446744073709551612, 18446744073709551615] exceeds maximum object size 9223372036854775807 [-Wstringop-overread] 1164 | cmp = memcmp(a, b, Min(lena, lenb)); | ^~ which does not seem plausible ;). As far as I can tell the values actually passed to memcmp are reasonable. I've attached both the preprocessed source file. I tried to reduce it using creduce - but it hung and reported a bug (which I did, an hour ago). andres@awork3:~/src/postgresql$ gcc-11 --version gcc-11 (Debian 11.1.0-1) 11.1.0 This also happens with gcc-10 (except reported as -Wstringop-overflow=), but not 9. Regards, Andres
[Bug c/80076] -Wmisleading-indentation doesn't trigger when macro is misindented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80076 --- Comment #4 from Andres Freund --- (In reply to Patrick Palka from comment #3) > Fixed for GCC 11. Thanks for the report. Thanks!
[Bug c/87489] Spurious -Wnonnull warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87489 --- Comment #2 from Andres Freund --- Maybe (In reply to Jonathan Wakely from comment #1) > The first XLogRegisterData could change the value of xl_xinfo.xid to be > non-zero, in which case the second XLogRegisterData call would happen > despite the null string. Well, that'd then still only be a ok for a "may be" warning, not one that say "argument 1 null where" (i.e. without a may be). Also, XLogRegisterData here takes a const char * argument, so it really shouldn't modify the argument?
[Bug c/87489] New: Spurious -Wnonnull warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87489 Bug ID: 87489 Summary: Spurious -Wnonnull warning Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: andres at anarazel dot de Target Milestone: --- Created attachment 44775 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44775&action=edit Repro Hi, With the attached, obviously heavily condensed, testcase I get a spurious -Wnonnull warning. It's quite true that the argument to strlen is NULL, but the code isn't reachable if so. As the warning isn't phrased as "may be", that doesn't seem quite right. $ gcc-8 -Wnonnull -O2 -c xact.stripped.i In function ‘XactLogCommitRecord.constprop’, inlined from ‘RecordTransactionCommit’ at xact.stripped.i:51:3: xact.stripped.i:44:50: warning: argument 1 null where non-null expected [-Wnonnull] XLogRegisterData((const char *) twophase_gid, strlen(twophase_gid) + 1); ^~~~ xact.stripped.i: In function ‘RecordTransactionCommit’: xact.stripped.i:19:15: note: in a call to function ‘strlen’ declared here extern size_t strlen (const char *__s) ^~ While the concrete problem in postgres only triggers for gcc-8 at -O3, the simplified testcase triggers for 7, 8, and a recent-ish trunk, and even with -O1. Without the first XLogRegisterData() call the warning does not appear. - Andres
[Bug c++/85601] New: [8 Regression] anonymous struct & union namespace conflict in extern C block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85601
Bug ID: 85601
Summary: [8 Regression] anonymous struct & union namespace
conflict in extern C block
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
Target Milestone: ---
Hi,
When compiling with g++ anonymous structs / unions inside C functions conflict
based on their variable name. That wasn't previously the case and doesn't seem
to make much sense.
Ex.:
extern "C"
{
static inline void funca(void)
{
union
{
int a;
} myunion;
(void) myunion;
}
static inline void funcb(void)
{
union
{
int a;
} myunion;
(void) myunion;
}
}
andres@alap4:~/src/postgresql$ /usr/lib/gcc-snapshot/bin/g++ --version
g++ (Debian 20180425-1) 9.0.0 20180425 (experimental) [trunk revision 259645]
..
andres@alap4:~/src/postgresql$ /usr/lib/gcc-snapshot/bin/g++ -c -o /tmp/frak.o
/tmp/frak.cc
/tmp/frak.cc: In function 'void funcb()':
/tmp/frak.cc:18:9: warning: conflicting C language linkage declaration
'funcb():: myunion'
} myunion;
^~~
/tmp/frak.cc:8:9: note: previous declaration 'funca():: myunion'
} myunion;
^~~
If I rename one of the *variables* in the *independent* functions the error
vanishes.
This currently triggers inside PostgreSQL's master branch (which now uses C++
for an optional module).
Regards,
Andres Freund
[Bug c/80076] New: -Wmisleading-indentation doesn't trigger when macro is misindented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80076
Bug ID: 80076
Summary: -Wmisleading-indentation doesn't trigger when macro is
misindented
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
CC: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 40989
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40989&action=edit
reproducer
Hi,
-Wmisleading-indentation doesn't trigger when the misindented part of the code
consists of a macro. The attached example is silent when a macro is used, and
warns when a function is used.
#ifdef TRIGGER
static void elog(char *msg) { }
#else
#define elog(Y) printf(Y)
#endif
void foo (void);
void test (int flag)
{
if (flag)
foo ();
elog("could not identify CTID variable");
}
andres@alap4:~$ gcc -DTRIGGER -Wmisleading-indentation -c /tmp/repro.c
/tmp/repro.c: In function 'test':
/tmp/repro.c:13:3: warning: this 'if' clause does not guard...
[-Wmisleading-indentation]
if (flag)
^~
/tmp/repro.c:15:5: note: ...this statement, but the latter is misleadingly
indented as if it were guarded by the 'if'
elog("could not identify CTID variable");
^~~~
andres@alap4:~$ gcc -Wmisleading-indentation -c /tmp/repro.c
andres@alap4:~$ gcc --version
gcc (Debian 20170226-1) 7.0.1 20170226 (experimental) [trunk revision 245744]
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Not sure if this is a known "issue", or not. If it's hard to make that work
reliably for macros...
Andres
[Bug rtl-optimization/71785] Computed gotos are mostly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785 --- Comment #6 from Andres Freund --- Hi, Can confirm this patch fixes the specific code generation issue I complained about, leading to an overall 1.9% improvement in TPC-H performance. There's still some counterproductive jumps, but they're unrelated to computed goto. Thanks, Andres
[Bug c/71785] Computed gotos are mostly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785 --- Comment #1 from Andres Freund --- Created attachment 38845 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38845&action=edit reproducer
[Bug c/71785] New: Computed gotos are mostly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785 Bug ID: 71785 Summary: Computed gotos are mostly optimized away Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: andres at anarazel dot de Target Milestone: --- Hi, I'm working on some interpreter like constructs in postgres. To reduce the number of mispredictions I wanted to use the "typical" jump threading approach. Unfortunately with gcc-6 (gcc-6 (Debian 6.1.1-8) 6.1.1 20160630) and up to a recent snapshot (Debian 20160612-1) 7.0.0 20160612 (experimental) [trunk revision 237336]), gcc merges some of the gotos together in a common label, and jumps there. In the attached file (a small artifical case showing the problem), with -O3 this results in CASE_OP_A: someglobal++; op++; goto *dispatch_table[op->opcode]; CASE_OP_B: do_stuff_b(op->arg); op++; goto *dispatch_table[op->opcode]; being implemented as .L5: addq$8, %rbx jmp *%rax ... .L3: movl(%rbx), %eax addl$1, someglobal(%rip) movqdispatch_table.1772(,%rax,8), %rax jmp .L5 ... .L4: movl-4(%rbx), %edi calldo_stuff_b movl(%rbx), %eax movqdispatch_table.1772(,%rax,8), %rax jmp .L5 I've tried -fno-gcse and -fno-crossjumping, and neither seems to fix the problem. It's also kind of weird how the load from the dispatch table is still performed in the individual branches, just the final jmp *%rax happens in the common location (L5 here). In the actual case I'm fighting with gcc "inlines" the jmp *%rax in one of the dispatches, but not in the other 8. Any additional information I can provide? Regards, Andres
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between < 4.9 and 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 --- Comment #5 from Andres Freund --- Hi, On 2014-04-30 15:48:33 +, pinskia at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 > > --- Comment #4 from Andrew Pinski --- > It was not on accident, see > http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00260.html and > http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02077.html > > And even where I said http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02078.html > > This was all discussed on the list and there was no objections. Meh. At the very least you should document such changes in the release notes. I'd be surprised if I am the only one that wasted time on debugging this change. Greetings, Andres Freund
[Bug debug/61013] Option parsing difference between < 4.9 and 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 --- Comment #2 from Andres Freund --- Hi, On 2014-04-30 14:54:20 +, pinskia at gcc dot gnu.org wrote: > -g is the same as -g2 and the later option is supposed to override the first > one. Jus like how -O is handled. The point is that this has changed between 4.8 and 4.9... And I don't see anything relevant in http://gcc.gnu.org/gcc-4.9/changes.html Greetings, Andres Freund
[Bug debug/61013] New: Option parsing difference between < 4.9 and 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 Bug ID: 61013 Summary: Option parsing difference between < 4.9 and 4.9 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: andres at anarazel dot de In gcc 4.8 a binary compiled with "gcc -g3 ... -g" would include the extended debug information (e.g. macros), while in gcc 4.9 the second -g seems to lower the debug level. That's obviously not a critical issue, but it's annoying enough because several buildsystems add -g internally, often after the user supplied CFLAGS, making it harder to build with a sufficient amount of debuginfo.
