https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110441
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Patrick Palka <ppa...@gcc.gnu.org>: https://gcc.gnu.org/g:0de651db45c758f54e9ed917069795a3835499de commit r14-2539-g0de651db45c758f54e9ed917069795a3835499de Author: Patrick Palka <ppa...@redhat.com> Date: Sat Jul 15 09:50:51 2023 -0400 c++: copy elision w/ obj arg and static memfn call [PR110441] Here the call A().f() is represented as a COMPOUND_EXPR whose first operand is the otherwise unused object argument A() and second operand is the call result (both are TARGET_EXPRs). Within the return statement, this outermost COMPOUND_EXPR ends up foiling the copy elision check in build_special_member_call, resulting in us introducing a bogus call to the deleted move constructor. (Within the variable initialization, which goes through ocp_convert instead of convert_for_initialization, we've already been eliding the copy -- despite the outermost COMPOUND_EXPR -- ever since r10-7410-g72809d6fe8e085 made ocp_convert look through COMPOUND_EXPR). In contrast I noticed '(A(), A::f())' (which should be equivalent to the above call) is represented with the COMPOUND_EXPR inside the RHS's TARGET_EXPR initializer thanks to a special case in cp_build_compound_expr. So this patch fixes this by making keep_unused_object_arg use cp_build_compound_expr as well. PR c++/110441 gcc/cp/ChangeLog: * call.cc (keep_unused_object_arg): Use cp_build_compound_expr instead of building a COMPOUND_EXPR directly. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/elide8.C: New test.
