https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78323
Bug ID: 78323 Summary: pathological code generation for long logical expression with temporary objects Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: froydnj at gcc dot gnu.org Target Milestone: --- Created attachment 40030 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40030&action=edit logical-or.cpp Compiling the attached testcase -O2 -std=c++11 reveals a significant disparity in the code GCC produces versus clang: froydnj@thor:~$ gcc -O2 -std=c++11 -c logical-or-gcc.cpp froydnj@thor:~$ clang -O2 -std=c++11 -c logical-or.cpp -o logical-or-clang.o froydnj@thor:~$ size logical-or*.o text data bss dec hex filename 633354 0 0 633354 9aa0a logical-or-gcc.o 17628 0 0 17628 44dc logical-or-clang.o That was with GCC 4.9; a colleague tried it with GCC 6.2.0 and got: text data bss dec hex filename 591843 8 0 591851 907eb logical-or.o which is some kind of improvement, but not enough of one. I gone over the assembly with a fine-toothed comb or looked at the tree dumps, but I think GCC is falling into some kind of O(n^2) situation where it sets a flag for the constructed status of every temporary object after each exit from the chained condition.