https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86849
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Richard Smith from comment #1)
> Interestingly, GCC does appear to suppress guaranteed copy elision if the
> class has virtual base classes.
>
>
> Perhaps GCC's approach to this problem is to assume that a function
> returning a T by value cannot touch the tail padding of the T object if T is
> POD for the purpose of layout, and so the tail padding cannot be modified in
> the case where it's reusable by the enclosing object? (So we only have a
> problem in the case where a complete-object constructor and a base-subobject
> constructor would do different things, namely when the class has virtual
> base classes.)
>
> The trouble with that approach is that other compilers do store to the tail
> padding of T in a function returning T by value:
>
> https://godbolt.org/g/MM7Wvb
>
> ... and indeed the standard requires this behavior:
>
> http://eel.is/c++draft/dcl.init#6.2
>
> "To zero-initialize an object or reference of type T means [...] if T is a
> (possibly cv-qualified) non-union class type, its padding bits (6.7) are
> initialized to zero bits [...]"
>
> (so arguably that's another bug in GCC's behavior: it should zero-initialize
> A's tail padding in the new example, but does not).
I wonder if that's PR85548.
