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.