[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!
