[Bug c++/110441] New: c++17 deferred materialization of temporaries fails when calling class static with member syntax

[Bug c++/110441] New: c++17 deferred materialization of temporaries fails when calling class static with member syntax

[eric.niebler at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110441

            Bug ID: 110441
           Summary: c++17 deferred materialization of temporaries fails
                    when calling class static with member syntax
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eric.niebler at gmail dot com
  Target Milestone: ---

struct immovable {
  immovable() = default;
  immovable(immovable &&) = delete;
};

struct S {
  static immovable f() {
    return {};
  }
};

immovable g() { 
  return S().f();
}

compile with -std=c++17. Result:

<source>: In function 'immovable g()':
<source>:14:15: error: use of deleted function
'immovable::immovable(immovable&&)'
   14 |   return S().f();
      |          ~~~~~^~
<source>:4:3: note: declared here
    4 |   immovable(immovable &&) = delete;
      |   ^~~~~~~~~


https://godbolt.org/z/Y1h9bPrf3

[Bug c++/110441] c++17: temporary causes static member function call to confuse required copy elision

[gasper.azman at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110441

Gašper Ažman <gasper.azman at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gasper.azman at gmail dot com

--- Comment #1 from Gašper Ažman <gasper.azman at gmail dot com> ---
I hit this in gcc 10 as well when implementing sender/receiver. Was not able to
reduce it this nicely, so I didn't report. Nice work, Eric.

[Bug c++/110441] c++17: temporary causes static member function call to confuse required copy elision

[gasper.azman at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110441

--- Comment #2 from Gašper Ažman <gasper.azman at gmail dot com> ---
Some more color from twitter, courtesy of @matthewecross:

Interestingly both "return S::f();" and "auto s = S(); return s.f();" both
pass.  It's only when you create a temporary instance of S in the return
statement that it fails.

[Bug c++/110441] c++17: temporary causes static member function call to confuse required copy elision

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110441

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-06-28
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |ppalka at gcc dot gnu.org

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Confirmed, this never worked.  The problem seems to be that because f is
static, 'S().f()' is represented as a COMPOUND_EXPR that evaluates the
otherwise unused object argument S() followed by a TARGET_EXPR for S::f().  And
this COMPOUND_EXPR foils the copy elision check in build_special_member_call
which looks only for an outermost TARGET_EXPR and doesn't look through
COMPOUND_EXPR.

In contrast, '(S(), S::f())' (which should be equivalent) is represented as a
TARGET_EXPR of a COMPOUND_EXPR rather than a COMPOUND_EXPR of a TARGET_EXPR,
and so copy elision is correctly avoided.  So perhaps we could make
keep_unused_object_arg for a TARGET_EXPR result place the COMPOUND_EXPR inside
the TARGET_EXPR_INITIAL instead of around the TARGET_EXPR?

[Bug c++/110441] c++17: temporary causes static member function call to confuse required copy elision

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110441

--- Comment #4 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Patrick Palka from comment #3)
> In contrast, '(S(), S::f())' (which should be equivalent) is represented as
> a TARGET_EXPR of a COMPOUND_EXPR rather than a COMPOUND_EXPR of a
> TARGET_EXPR, and so copy elision is correctly avoided.
oops, this should say "is correctly _performed_"

[Bug c++/110441] c++17: temporary causes static member function call to confuse required copy elision

[matt.cross+gcc-bugzilla at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110441

Matt Cross <matt.cross+gcc-bugzilla at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matt.cross+gcc-bugzilla@gma
                   |                            |il.com

--- Comment #5 from Matt Cross <matt.cross+gcc-bugzilla at gmail dot com> ---

I have also found that
* Making the function f() non-static works.  https://godbolt.org/z/jn6Ms1n5h
* Making a unique_ptr to an S fails: "auto sp = std::make_unique<S>(); return
sp->f();"  https://godbolt.org/z/85e9MW91b

I suspect it is the same root cause, but just in case there's wrinkles here I
thought these additional test cases might be helpful.

[Bug c++/110441] c++17: temporary causes static member function call to confuse required copy elision

[cvs-commit at gcc dot gnu.org]

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 <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:0de651db45c758f54e9ed917069795a3835499de

commit r14-2539-g0de651db45c758f54e9ed917069795a3835499de
Author: Patrick Palka <ppalka@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.

[Bug c++/110441] c++17: temporary causes static member function call to confuse required copy elision

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110441

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org
   Target Milestone|---                         |14.0
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Should be fixed for GCC 14, thanks for the report.