[Bug c/38616] New: Wrong code when -O3 or -O2 used
I'm using generic Ubuntu Intrepid desktop i386 system.
My program:
#include
int main (void)
{
char buffer[1024]="";
sprintf (buffer, "%s", "1234567890abcdefghijklmno");
printf ("%s\n", buffer);
return 0;
}
--
It will print '12345678' if -O2 or -O3 is used. If no optimizations used, it
print full string as in source. If I replace 'char buffer[1024]="";' with
'char buffer[1024];' it will work just fine with any optimizations. WTF?
--
mma...@mmarkk-desktop:~$ LANG=C gcc -O2 -v zzz2.c
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11)
COLLECT_GCC_OPTIONS='-O2' '-v' '-mtune=generic'
/usr/lib/gcc/i486-linux-gnu/4.3.2/cc1 -quiet -v zzz2.c -D_FORTIFY_SOURCE=2
-quiet -dumpbase zzz2.c -mtune=generic -auxbase zzz2 -O2 -version
-fstack-protector -o /tmp/ccxjcnkd.s
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/i486-linux-gnu/4.3.2/include
/usr/lib/gcc/i486-linux-gnu/4.3.2/include-fixed
/usr/include
End of search list.
GNU C (Ubuntu 4.3.2-1ubuntu11) version 4.3.2 (i486-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: fbed29247d8ae538bfd0dd565a17225f
COLLECT_GCC_OPTIONS='-O2' '-v' '-mtune=generic'
as -V -Qy -o /tmp/ccy32lKh.o /tmp/ccxjcnkd.s
GNU assembler version 2.18.93 (i486-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.18.93.20081009
COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-O2' '-v' '-mtune=generic'
/usr/lib/gcc/i486-linux-gnu/4.3.2/collect2 --eh-frame-hdr -m elf_i386
--hash-style=both -dynamic-linker /lib/ld-linux.so.2 -z relro
/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crt1.o
/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crti.o
/usr/lib/gcc/i486-linux-gnu/4.3.2/crtbegin.o
-L/usr/lib/gcc/i486-linux-gnu/4.3.2 -L/usr/lib/gcc/i486-linux-gnu/4.3.2
-L/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.2/../../.. /tmp/ccy32lKh.o
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib/gcc/i486-linux-gnu/4.3.2/crtend.o
/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crtn.o
--
Summary: Wrong code when -O3 or -O2 used
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: socketpair at gmail dot com
GCC build triplet: i386
GCC host triplet: i386
GCC target triplet: i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38616
[Bug c/38616] Wrong code when -O3 or -O2 used
--- Comment #1 from socketpair at gmail dot com 2008-12-24 13:27 --- Created an attachment (id=16979) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16979&action=view) assembler output of wrong generated code this assembler output generates only 8 characters in output instead of full constant string. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38616
[Bug c/38616] Wrong code when -O3 or -O2 used
--- Comment #2 from socketpair at gmail dot com 2008-12-24 13:33 --- (From update of attachment 16979) .file "zzz2.c" .text .p2align 4,,15 .globl main .type main, @function main: leal4(%esp), %ecx andl$-16, %esp pushl -4(%ecx) pushl %ebp movl%esp, %ebp subl$1064, %esp movl%gs:20, %eax movl%eax, -12(%ebp) xorl%eax, %eax movl%ecx, -8(%ebp) movl$255, %ecx movl%edi, -4(%ebp) leal-1032(%ebp), %edi movl$875770417, -1036(%ebp) movl$1650536505, -1028(%ebp) movl$1717920867, -1024(%ebp) rep stosl leal-1036(%ebp), %eax movl$943142453, -1032(%ebp) movl$1785292903, -1020(%ebp) movl$1852664939, -1016(%ebp) movw$111, -1012(%ebp) movl%eax, (%esp) callputs xorl%eax, %eax movl-12(%ebp), %edx xorl%gs:20, %edx jne .L6 movl-8(%ebp), %ecx movl-4(%ebp), %edi movl%ebp, %esp popl%ebp leal-4(%ecx), %esp ret .L6: call__stack_chk_fail .size main, .-main .ident "GCC: (Ubuntu 4.3.2-1ubuntu11) 4.3.2" .section.note.GNU-stack,"",@progbits -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38616
[Bug c/38616] Wrong code when -O3 or -O2 used
--- Comment #3 from socketpair at gmail dot com 2008-12-24 13:38 --- (From update of attachment 16979) (i'm not intentionally send assembler output for version where buf[1024] replaced with buf[1023]). -- socketpair at gmail dot com changed: What|Removed |Added Attachment #16979|assembler output of wrong |assembler output of wrong description|generated code |generated code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38616
[Bug middle-end/38616] [4.3 only] Wrong code when -O3 or -O2 -fstack-protector used
--- Comment #5 from socketpair at gmail dot com 2008-12-24 15:21 --- -fno-stack-protector really helps. i don't understand why "rep stosl" appear in the middle of string initialization.. gdb said that "rep stosl" is a cause of zero byte after first 8 symbols. also, if this bug does not appear in 4.4.0, i want to see decription of corrected bug (maybe dup of mine) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38616
[Bug middle-end/38616] [4.3 only] Wrong code when -O3 or -O2 -fstack-protector used
--- Comment #6 from socketpair at gmail dot com 2008-12-24 15:28 --- > -fno-fstack-protector is a work around. Ubuntu must enable stack protector by default. I don't understand. Ubuntu enabled stack protector by default now. Is this error? Should i report bug to Ubuntu? It stack protector experimental feature? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38616
[Bug c/54340] New: internal compiler error: Illegal instruction (int main() returns nothing, only when -O2/-O3 used)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54340
Bug #: 54340
Summary: internal compiler error: Illegal instruction (int
main() returns nothing, only when -O2/-O3 used)
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: socketp...@gmail.com
$ gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 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 test.c
$ LANG=C gcc -O2 test.c
test.c: In function 'main':
test.c:6:1: internal compiler error: Illegal instruction
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/ccYojEN6.out file, please attach this to
your bugreport.
$ cat test.c
int main (void)
{
volatile int a;
if (a == 42)
return 1;
}
If I add "return 0;" to the end of function - problem is fixed. I understand,
that program is not correct, but, as I think, gcc should not fail on that. It
seems, it is optimizer bug.
[Bug c/54340] internal compiler error: Illegal instruction (int main() returns nothing, only when -O2/-O3 used)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54340 --- Comment #3 from Коренберг Марк 2012-08-21 07:32:25 UTC --- Yes, I tested on gentoo, no error appear. I have reported to ubuntu bug tracker: https://bugs.launchpad.net/ubuntu/+source/gcc-4.6/+bug/1039401
[Bug c/41749] New: non-needed instructions are not removed (not optimized)
int main (void) {return 1; }
Ubuntu Jaunty.
gcc --save-temps -fno-stack-protector -fomit-frame-pointer -Os ./cpuid.c
generates thgis:
--
main:
leal4(%esp), %ecx
andl$-16, %esp
pushl -4(%ecx)
movl$1, %eax
pushl %ecx
popl%ecx
leal-4(%ecx), %esp
ret
--
why i get this:
pushl %ecx
popl%ecx
and other non-needed instructions (for another example)
pushl %ebp
andl$1, %eax
movl%esp, %ebp
pushl %ecx
popl%ecx
popl%ebp
These instructions are not optimized not in -O3, nor in -Os
--
Summary: non-needed instructions are not removed (not optimized)
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: socketpair at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41749
[Bug c/41749] non-needed instructions are not removed (not optimized)
--- Comment #1 from socketpair at gmail dot com 2009-10-19 07:14 --- gcc322 generates this: (gcc -Os -fomit-frame-pointer qwe.c --save-temps) main: movl$1, %eax ret WTF? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41749
[Bug c/70308] New: memset generates rep stosl instead of rep stosq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70308
Bug ID: 70308
Summary: memset generates rep stosl instead of rep stosq
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: socketpair at gmail dot com
Target Milestone: ---
Consider this program:
=
#include
#include
#include
int main() {
char buf[128];
if (scanf("%s", buf) != 1) return 42;
memset(buf,0, 128);
asm volatile("": : :"memory");
return 0;
}
==
compile with -O3
and you will see, that memset is translated to "rep stosl". good.
Next, comment line with scanf() and compile again
and you will see, that memset is translated to "rep stosq", which is much
faster.
So, I consider that gcc should emit "rep stosq" in both cases.
[Bug c/70308] memset generates rep stosl instead of rep stosq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70308 --- Comment #2 from Коренберг Марк --- Please read carefully. All conditions are the same, except different branching. So, gcc choose "rep stosl" by unknown cause.
[Bug lto/68902] New: --as-needed consider library as unneeded even when library have __init functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68902
Bug ID: 68902
Summary: --as-needed consider library as unneeded even when
library have __init functions
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: socketpair at gmail dot com
Target Milestone: ---
Original bug was reported here:
https://github.com/thom311/libnl/issues/93
libnl3 have such function:
static void __init ct_init(void)
{
nl_cache_mngt_register(&nfnl_ct_ops);
}
so, when this library is loaded it register itself in some global variable for
later access.
When I link against that library, my program does not see that registration
since library just is not linked!
I consider gcc should not eliminate lbraries where __init functions exists.
[Bug lto/68902] --as-needed consider library as unneeded even when library have __init functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68902 --- Comment #2 from Коренберг Марк --- https://sourceware.org/bugzilla/show_bug.cgi?id=19372
[Bug tree-optimization/45340] New: __builtin_expect and -Os generates stupid code
__builtin_expect and -Os generates stupid code like jump to next instruction. I will attach sources and generated asm listing. -- Summary: __builtin_expect and -Os generates stupid code Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: socketpair at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45340
[Bug tree-optimization/45340] __builtin_expect and -Os generates stupid code
--- Comment #1 from socketpair at gmail dot com 2010-08-19 14:17 --- Created an attachment (id=21519) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21519&action=view) C souce file 1. gcc-Os --save-temps -fomit-frame-pointer -fno-stack-protector main.c 2. gcc -DCOOL -Os --save-temps -fomit-frame-pointer -fno-stack-protector main.c compare .s files You will see this: - testl %eax, %eax je .L2 jmp .L7 .L4: .L7: cmpl$0, 12(%esp) - I think, that "jmp .L7" is stupid -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45340
[Bug tree-optimization/45340] __builtin_expect and -Os generates stupid code
--- Comment #2 from socketpair at gmail dot com 2010-08-19 14:28 --- Created an attachment (id=21520) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21520&action=view) with stupid jmp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45340
[Bug tree-optimization/45340] __builtin_expect and -Os generates stupid code
--- Comment #3 from socketpair at gmail dot com 2010-08-19 14:28 --- Created an attachment (id=21521) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21521&action=view) without buggy jmp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45340
[Bug tree-optimization/45340] __builtin_expect and -Os generates stupid code
--- Comment #5 from socketpair at gmail dot com 2010-08-24 03:35 --- > There is nothing the compiler can do really. Why ? I compared assembler listings with likely() swapped with unlikely(). As I suggest, it helps to choose between je and jne in each case, and other circumstances are not taken into account. So on this, I conclude that this optimization is made near the end of compilation. Consequently, the bug in it. -- socketpair at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45340
[Bug tree-optimization/45340] __builtin_expect and -Os generates stupid code
--- Comment #7 from socketpair at gmail dot com 2010-08-25 12:23 --- Well, I understand that problem is not in __builtin_expect. Should I open new, separate bug about block reordering and generating "jmp to next line" ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45340
[Bug inline-asm/43998] New: inline assembler: can't set clobbering for input register
mma...@mmarkk-desktop:~/src/vmdetect$ gcc --version
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
--
#include
#include
int main (void)
{
size_t ecx;
asm ("cpuid": "=c" (ecx): "a" (0x1):"eax","ebx","edx");
printf ("Suspected %s machine!\n", (ecx >> 31) ? "virtual" : "real");
return 0;
}
mma...@mmarkk-desktop:~/src/vmdetect$ gcc 1main.c
1main.c: In function main:
1main.c:7: error: can't find a register in class AREG while reloading asm
1main.c:7: error: asm operand has impossible constraints
#include
#include
int main (void)
{
size_t ecx, dontneed;
asm ("cpuid": "=c" (ecx),"=a"(dontneed): "a" (0x1):"ebx","edx");
printf ("Suspected %s machine!\n", (ecx >> 31) ? "virtual" : "real");
return 0;
}
works OK.
How to correctly say compiler about clobbering eax register ?
--
Summary: inline assembler: can't set clobbering for input
register
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: socketpair at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43998
[Bug inline-asm/43998] inline assembler: can't set clobbering for input register
--- Comment #3 from socketpair at gmail dot com 2010-05-06 11:00 --- Thanks alot, but I think it is bug in gcc inline assembler. I think I wrote correct asm() line. I know about cpuid.h I listed this instruction just as example. -- socketpair at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43998
[Bug inline-asm/43998] inline assembler: can't set clobbering for input register
--- Comment #5 from socketpair at gmail dot com 2010-05-06 11:41 --- Well, how to say that to compiler: This instruction receives input in register eax, but after executing it, eax value will be corrupted. I don't need this new value, but compiler should not think that eax is preserved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43998
[Bug inline-asm/43998] inline assembler: can't set clobbering for input register
--- Comment #7 from socketpair at gmail dot com 2010-05-06 13:42 --- > Just make eax both input and output. it's not optimal. gcc will try to preserve new eax value. So it will not use eax register in next instructions. If eax is really need, it will save it in esi, edi or so on - it's redundant. -- socketpair at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43998
[Bug inline-asm/43998] inline assembler: can't set clobbering for input register
--- Comment #9 from socketpair at gmail dot com 2010-05-06 15:03 --- > Not if you make the output unused by not using it. I do not understand why gcc distinguish between 'specifying register as output' and 'specifying as clobbering'. I always considered, that 'clobber list' specify list of items which may be changed *AFTER* the end of instruction(s). So I do not understand why adding eax in clobber list will break compilation. I found some posts where people create size_t dummy; and specify this variable as output. insted of just specifying this register in clobber-list. Why not to fix bug I have reported? Maybe convert to feature? -- socketpair at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43998
[Bug c/44094] New: case xxx statement does not recognize const int value
switch(xxx)
{
case *(const int* const)"abc":
break;
}
does not get compiled. saying:
error: case label does not reduce to an integer constant
I think it is the bug.
--
Summary: case xxx statement does not recognize const int value
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: socketpair at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44094
[Bug inline-asm/43998] inline assembler: can't set clobbering for input register
--- Comment #11 from socketpair at gmail dot com 2010-05-14 06:31 ---
Suppose this:
volatile int x;
asm("something"::"a" (1))
x=1;
the compiler may think that "something" do not modify eax. So next assignment
may use eax ( mov eax, x ). So, "it does not make sense to have it as a
clobber" is not correct. does not it ?
-
And the second, "Because the way the constraints are implemented inside GCC, an
input constraint cannot overlap with a clobber." - It definitely the bug.
--
socketpair at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43998
[Bug tree-optimization/108418] New: gcc does not optimize trivial code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108418
Bug ID: 108418
Summary: gcc does not optimize trivial code
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: socketpair at gmail dot com
Target Milestone: ---
https://godbolt.org/z/s3j8jK6ca
```
#include
int firewall1(const uint8_t *restrict data) {
const uint8_t ip_proto = *data;
const uint16_t dst_port = *((const uint16_t *)data + 32);
const uint16_t qwe = *((const uint16_t *)data + 64);
if (ip_proto == 17 && dst_port == 17 && qwe == 42) return 1;
if (ip_proto == 17 && dst_port == 23 && qwe == 42) return 1;
if (ip_proto == 17 && dst_port == 45 && qwe == 42) return 1;
if (ip_proto == 17 && dst_port == 63 && qwe == 42) return 1;
if (ip_proto == 17 && dst_port == 0 && qwe == 42) return 1;
if (ip_proto == 17 && dst_port == 2 && qwe == 42) return 1;
if (ip_proto == 17 && dst_port == 3 && qwe == 42) return 1;
return 0;
}
int firewall2(const uint8_t *restrict data) {
const uint8_t ip_proto = *data;
const uint16_t dst_port = *((const uint16_t *)data + 32);
const uint16_t qwe = *((const uint16_t *)data + 64);
if (ip_proto == 17 && dst_port == 17) return 1;
if (ip_proto == 17 && dst_port == 23) return 1;
if (ip_proto == 17 && dst_port == 45) return 1;
if (ip_proto == 17 && dst_port == 63) return 1;
if (ip_proto == 17 && dst_port == 0) return 1;
if (ip_proto == 17 && dst_port == 2) return 1;
if (ip_proto == 17 && dst_port == 3) return 1;
return 0;
}
```
It can't understand common condition (ip_proto == 17 && qwe == 42).
But it can for simpler case in firewall2.
See godbolt assembler output.
[Bug tree-optimization/108418] gcc does not optimize trivial code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108418 --- Comment #1 from Коренберг Марк --- Sorry, but such kind of code happens as a result of C-code automatic generation.
[Bug regression/107767] New: GCC has some problems in optimizer of trivial case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
Bug ID: 107767
Summary: GCC has some problems in optimizer of trivial case
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: socketpair at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/rTfTondfP
```
#include
int firewall(const uint8_t *restrict data) {
const uint8_t ip_proto = *data;
const uint16_t dst_port = *((const uint16_t *)data + 32);
if (ip_proto == 17 && dst_port == 15) return 1;
if (ip_proto == 17 && dst_port == 23) return 1;
if (ip_proto == 17 && dst_port == 47) return 1;
if (ip_proto == 17 && dst_port == 45) return 1;
if (ip_proto == 17 && dst_port == 42) return 1;
if (ip_proto == 17 && dst_port == 1) return 1;
if (ip_proto == 17 && dst_port == 2) return 1;
if (ip_proto == 17 && dst_port == 3) return 1;
return 0;
}
int firewall2(const uint8_t *restrict data) {
const uint16_t dst_port = *((const uint16_t *)data + 32);
if (dst_port == 15) return 1;
if (dst_port == 23) return 1;
if (dst_port == 47) return 1;
if (dst_port == 45) return 1;
if (dst_port == 42) return 1;
if (dst_port == 1) return 1;
if (dst_port == 2) return 1;
if (dst_port == 3) return 1;
return 0;
}
```
Compile with -Os.
Second function IS NOT minimal, obviously. It's a bug. GCC 12.2 does not have
it.
[Bug regression/107767] GCC has some problems in optimizer of trivial case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767 --- Comment #1 from Коренберг Марк --- See assembler output for firewall2(). It's not -Os optimized (compare to firewall(), which is ok) ``` firewall: movw64(%rdi), %ax cmpb$17, (%rdi) sete%cl leal-15(%rax), %edx testw $-9, %dx movb$1, %dl sete%sil cmpw$47, %ax ja .L2 movabsq $-180319906955279, %rdx btq %rax, %rdx setc%dl .L2: movl%edx, %eax xorl$1, %eax orl %esi, %eax andl%ecx, %eax movzbl %al, %eax ret firewall2: movw64(%rdi), %ax xorl%edx, %edx decl%eax cmpw$46, %ax ja .L5 movzwl %ax, %eax movsbl CSWTCH.2(%rax), %edx .L5: movl%edx, %eax ret CSWTCH.2: .byte 1 .byte 1 .byte 1 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 1 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 1 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 1 .byte 0 .byte 0 .byte 1 .byte 0 .byte 1 ```
[Bug regression/107767] GCC has some problems in optimizer of trivial case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767 --- Comment #3 from Коренберг Марк --- I forgot to add. gcc 12.2 - everything is OK. gcc 13 - with bug.
[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767 --- Comment #5 from Коренберг Марк --- Not only -s problem. I think -O3 in gcc 12.2 will run faster than -O3 in gcc 13 (for this case). this code should not be treated as if-else-if-else-if. gcc 12 does its job right.
[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767 --- Comment #8 from Коренберг Марк --- Okay, but why switch-case is not handled using fast implementation using masks (when difference between smallest and biggest integer <=64 ? See the first function in my first message where it works as expected. Seems, the problem is not in converting to switch-case, but missing optimisation for switch-case case.
[Bug tree-optimization/108215] New: Does not optimize trivial case with bit operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108215
Bug ID: 108215
Summary: Does not optimize trivial case with bit operations
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: socketpair at gmail dot com
Target Milestone: ---
https://godbolt.org/z/5e3eKqPqs
```C
#include
int firewall3(const uint8_t *restrict data) {
const uint32_t src = *((const uint32_t *)data);
if ((src & 0x) == 0x1122) return 1;
if ((src & 0xFF00) == 0x11223300) return 1;
return 0;
}
int firewall4(const uint8_t *restrict data) {
const uint32_t src = *((const uint32_t *)data);
if ((src & 0xFF00) == 0x11223300) return 1;
if ((src & 0x) == 0x1122) return 1;
return 0;
}
```
```
firewall3:
movl(%rdi), %eax
xorw%ax, %ax
cmpl$287440896, %eax
sete%al
movzbl %al, %eax
ret
firewall4:
movl(%rdi), %eax
movl$1, %edx
movl%eax, %ecx
xorb%cl, %cl
cmpl$287453952, %ecx
je .L3
xorw%ax, %ax
xorl%edx, %edx
cmpl$287440896, %eax
sete%dl
.L3:
movl%edx, %eax
ret
```
firewall3(): Excellent!
firewall4(): FAIL!
It's obvious that order of comparisons in this example does not matter. So I
think misoptimisation of firewall4() is a bug.
[Bug c++/111577] New: -Os gives significantly bigger code than -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111577
Bug ID: 111577
Summary: -Os gives significantly bigger code than -O0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: socketpair at gmail dot com
Target Milestone: ---
Yes, I saw #35806, #41175 and others.
See https://godbolt.org/z/Pnh89Y3Yb
```
#include
using namespace std;
int main(int argc, char* argv[]) {
if (argv[0] == nullptr || argv[1] == nullptr) return 0;
string zxc(argv[0]);
string qwe(argv[1]);
string asd(argv[2]);
zxc = qwe + asd;
return zxc.size();
}
```
-Os -std=c++2b -march=skylake -m64 (615 bytes)
compare size with the smae, but with options:
-O0 -std=c++2b -march=skylake -m64 (409 bytes)
-O0 - is much LESS (!) in bytes. I think it's a bug.
[Bug tree-optimization/116518] New: GCC does not optimize-out useless operations. Clang does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116518
Bug ID: 116518
Summary: GCC does not optimize-out useless operations. Clang
does.
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: socketpair at gmail dot com
Target Milestone: ---
https://godbolt.org/z/d46448vqa
-std=c++23 -O3 -fno-exceptions
#include
#include
#include
#include
#include
using namespace std;
namespace {
consteval string gen() { return "xxx"; }
class qwe {
public:
consteval qwe(const string& str) : s(str.size()) { str.copy(x.data(), s); }
constexpr operator const vector() const {
return {x.cbegin(), x.cbegin() + s};
}
private:
// 1048576 is a clang limit
array x{};
size_t s;
};
} // namespace
int fun1() {
const vector v2{qwe(gen())};
return v2.size();
}
-
fun1():
subq$10024, %rsp
movl$10008, %edx
xorl%esi, %esi
movq%rsp, %rdi
callmemset
movl$3, %edi
movl$7895160, (%rsp)
calloperator new(unsigned long)
movzwl (%rsp), %edx
movl$3, %esi
movq%rax, %rdi
movw%dx, (%rax)
movzbl 2(%rsp), %edx
movb%dl, 2(%rax)
calloperator delete(void*, unsigned long)
movl$3, %eax
addq$10024, %rsp
ret
-
Clang:
fun1():
mov eax, 3
ret
