[Bug c++/78323] New: pathological code generation for long logical expression with temporary objects

[froydnj at gcc dot gnu.org]

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.