https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86849
--- Comment #1 from Richard Smith <richard-gccbugzilla at metafoo dot co.uk> --- 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).
