https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79161
Bug ID: 79161 Summary: possibly lost DCE optimization Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: skvadrik at gmail dot com Target Milestone: --- Created attachment 40553 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40553&action=edit a.c Consider the following example (a.c in attach): static void f(const char *s) { for (; *s++ == '0'; ); } int main(int argc, char **argv) { const char *s0 = argv[1]; for (int x = 0; x < 1000000000; ++x) f(s0); return 0; } Clang thinks this can be optimized to just 'return 0': $ clang++-3.9 -c -O2 a.c -oa.o && objdump -d a.o clang-3.9: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated a.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 <main>: 0: 31 c0 xor %eax,%eax 2: c3 retq While GCC doesn't: $ g++ -c -O2 a.c -oa.o && objdump -d a.o a.o: file format elf64-x86-64 Disassembly of section .text.startup: 0000000000000000 <main>: 0: 48 8b 4e 08 mov 0x8(%rsi),%rcx 4: ba 00 ca 9a 3b mov $0x3b9aca00,%edx 9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) 10: 48 89 c8 mov %rcx,%rax 13: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 18: 48 83 c0 01 add $0x1,%rax 1c: 80 78 ff 30 cmpb $0x30,-0x1(%rax) 20: 74 f6 je 18 <main+0x18> 22: 83 ea 01 sub $0x1,%edx 25: 75 e9 jne 10 <main+0x10> 27: 31 c0 xor %eax,%eax 29: c3 retq I'm not sure if optimization is rightful but it looks correct to me. I don't see any side effects in 'f' function.