[Bug other/102942] New: Implicit copy constructor not elided

[Bug other/102942] New: Implicit copy constructor not elided

[albin at yahoo dot com]

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

            Bug ID: 102942
           Summary: Implicit copy constructor not elided
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: albin at yahoo dot com
  Target Milestone: ---

This is seen on every GCC version. The copy-constructor for a class with a data
buffer only gets elided if the copy-constructor is user provided. So if I have
a copy-constructor that explicitly calls memcpy, the compiler will elide it
when it can (and thus NOT call memcpy), but if I do not declare any such
constructor, the compiler *will* call mempcy even if the call could be elided.

https://godbolt.org/z/5YvWTE847

#include <cstring>

struct StructWithImplicitCpyCtr
{
    StructWithImplicitCpyCtr();
    float data[5000];
};

struct StructWithExplicitMemCpyCpyCtr
{
    StructWithExplicitMemCpyCpyCtr();
    StructWithExplicitMemCpyCpyCtr(StructWithExplicitMemCpyCpyCtr const& other)
    { std::memcpy(data, other.data, sizeof(data)); }
    float data[5000];
};

void take(StructWithImplicitCpyCtr);
void take(StructWithExplicitMemCpyCpyCtr);

void foobar()
{
    // The copy constructor explicitly calls memcpy, but copy elision removes
it
    take(StructWithExplicitMemCpyCpyCtr());

    // Here there is no explicit copy constructor to elide, we should expect to
see
    // similar code generated, instead we see a call to memcpy!!!
    take(StructWithImplicitCpyCtr());
}

[Bug c++/102942] Implicit copy constructor not elided

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This has been discussed before but I can't find the bug report now. The
non-elided memcpy happens for trivially copyable types, and GCC doesn't try to
elide those.

[Bug c++/102942] Implicit copy constructor not elided

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=89695

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Maybe PR 89695

[Bug c++/102942] Implicit copy constructor not elided

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
And maybe another one to link to PR 101926, but I'll let pinskia decide that.

[Bug c++/102942] Implicit copy constructor not elided

[matthijsvanduin at gmail dot com]

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

Matthijs van Duin <matthijsvanduin at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matthijsvanduin at gmail dot com

--- Comment #4 from Matthijs van Duin <matthijsvanduin at gmail dot com> ---
This is indeed a duplicate of 89695. The copy constructor isn't being "elided",
there's no semantic expectation of it being invoked at all, you're simply
initializing the parameter of take(T) with a prvalue T(). As special exception
however C++ permits parameters and return values of trivially-copyable types
(such as int and StructWithImplicitCpyCtr) to be copied superfluously, which is
what you're observing. This exception exists to allow C++ ABIs to pass such
types in a C-ABI-compatible way, which may sometimes require copying (notably
when passing small types in register for efficiency), though gcc seems to make
a superfluous copy whenever it is _allowed_ rather than whenever it is
_needed_.