Undead objects ([basic.life]/8): why is reference rebinding (and const modification) allowed?

Question

The "undead" clause

I call the undead clause the C++ rule that after the destruction of an object, if a new object is created at the same address, it can sometimes be considered the same object as the old one. That rule always existed in C++ but with some changes on the additional conditions.

I was made to read the latest undead clause by this question. The revised conditions in Lifetime [basic.life]/8 are:

(8.1) the storage for the new object exactly overlays the storage location which the original object occupied, and

Well, duh. An object at a different address would not be the same object.

(8.2) the new object is of the same type as the original object (ignoring the top-level cv-qualifiers), and

Again, duh.

(8.4) neither the original object nor the new object is a potentially-overlapping subobject ([intro.object]).

It cannot a base class, classic (or a member with a special declaration that makes its address not unique). Again, duh.

(8.3) the original object is neither a complete object that is const-qualified nor a subobject of such an object, and

Now that's interesting. The object being replaced can't be either:

• a complete const object
• part of a complete const object

On the other hand, the object being resurrected can be:

1. a const member subobject
2. a subobject of such const member
3. an element in an array of const objects

Const subobject

So it seems to me that all of these objects x can be resurrected:

Const member subobject

struct CI {
  const int x;
};

CI s = { 1 };
new ((void*)&s.x) int(2);
int r = s.x; // OK, 2

Subobject of const member:

struct T {
  int x;
};

struct CT {
  const T m = { 1 };
};

CT s;
new ((void*)&s.m.x) int (2);
int r = s.m.x;

Element in an array of const objects:

const int x[1] = { 1 };
new ((void*)&x[0]) int (2);
int r = x[0];

Classes with const and reference members

Also object of class type with const or references members do not seem to be prohibited; the resurrected object is still called x.

Class with a const member:

struct CIM {
  CIM(int i): m(i) {}
  const int m;
};

CIM x(1);
new ((void*)&x) CIM(2);
int r = x.m; // OK, 2

Class with a reference member:

struct CRM {
  CRM (int &r): m(r) {}
  int &m;
};

int i=1,j=2;
CRM x(i);
new ((void*)&x) CRM(j);
int r = x.m; // OK, 2

The questions

1. Is that interpretation of the clause correct?
2. If so, is there any other clause that forbid these overwriting operations?
3. If so, is that intended? Why was that changed?
4. Is that a breaking change for code generators? Do all compilers really support that? Don't they optimize based on const members, const elements of arrays being immutable and references not being reboundable?
5. BONUS QUESTION: does that affect ROM-ability of const objects with adequate storage class (not dynamically created objects, of course) and adequate initialize?

Note: I added the bonus later because putting constants in ROM came up in the discussion.

Answer 1

It would be surprising if all requirement of the standard related to object life-time were not in [basic-life].

There are few chances that the "complete" adjective has been inadvertedly added to the name "object" in the standard paragraph you cite.

In the paper P0137, one can read this rational (paper cited in @LanguageLawyer comment below):

This is necessary to allow types such as std::optional to contain const subobjects; the existing restriction exists to allow ROMability, and so only affects complete objects.

To reassure us, we can verify that compilers do follow the standard wording at the letter: they perform constant optimization for complete const objects but not for const member suboject of non const complete objects:

Let's consider this code:

struct A{const int m;};

void f(const int& a);

auto g(){
    const int x=12;
    f(x);
    return x;
}

auto h(){
    A a{12};
    f(a.m);
    return a.m;
}

Both Clang and GCC generates this assembly when targeting x86_64:

g():                                  # @g()
        push    rax
        mov     dword ptr [rsp + 4], 12
        lea     rdi, [rsp + 4]
        call    f(int const&)
        mov     eax, 12     ;//the return cannot be anything else than 12
        pop     rcx
        ret
h():                                  # @h()
        push    rax
        mov     dword ptr [rsp], 12
        mov     rdi, rsp
        call    f(int const&)
        mov     eax, dword ptr [rsp]  //the content of a.m is returned
        pop     rcx
        ret

The returned value is placed in register eax (according to the ABI specification: System V x86 processor specific ABI):

• In the function g the compiler is free to suppose that x can not be changed accross the call to f because x is a complete const object. So the value 12 is placed directly in the eax register as an immediate value: mov eax, 12.

• In the function h the compiler is not free to suppose that a.m can not be changed accross the call to f because a.m is not a suboject of a complete const object. So after the call to f the value of a.m must be loaded from memory to eax : mov eax, dword ptr [rsp].

Answer 2

Most of the necessary bits of the answer have already been given by other users, so I am collecting them in a community wiki so that this question can have an accepted answer.

1. Yes, other than with respect to a const array (as pointed out in the comments by T.C.). An array whose elements are const is itself a const object, so if it is the complete object, then its elements cannot be destroyed and recreated in place (as pointed out in the comments by walnut).

2. No. As Language Lawyer pointed out in the comments, the fact that it's allowed was explicitly intended. The Russian national body asked for it to be allowed, and C++20 was correspondingly amended to allow it.

3. See above.

4. • As pointed out in Oliv's answer, compilers are indeed aware that they're not supposed to optimize based on the assumption that a const member of a non-const complete object can't be replaced---because the standard says that they can be replaced.
   • The OP also asks whether this is a "breaking change". Well, in what sense? Since C++17 did not allow this form of replacement (leading to likely UB if attempted) and C++20 did allow it, it means that if the behaviour of a compiler changed in order to implement the C++20 behaviour, then there would be less UB, which is not a breaking change.
   • Did compilers ever perform this kind of optimization in the C++17 era, which was subsequently disallowed by C++20? The Russian national body comment hints at a decent argument as to why the answer is likely "no". The linked US national body comment is even more explicit. An example of the code that would have been broken by this kind of optimization is given at the end of this answer to avoid formatting issues. Here, the first S object created in v is destroyed and then a new S object is created in its place. v.data() is a pointer that originally pointed to the old object. Does it now point to the new object (resulting in 2 being printed) or does it point to no object, resulting in UB? I think we can safely assume that no widely used compiler would treat this code as UB in order to apply the optimization that was technically allowed in C++17. (Of course, there are caveats: compilers could have used magic to turn off this optimization in standard library classes, or they could have made the push_back operation always replace the stored pointer with a laundered version of itself, but in practice, this was not done.) In general, it does not seem that compilers had to change their behaviour due to the relaxation of the replacement rules in C++20.

5. No it doesn't. Obviously only complete const objects were ever ROMable in the first place (not const subobjects of non-const complete objects), and as discussed, complete const objects aren't affected by this change.

Code:

     #include <iostream>
     #include <vector>
     struct S {
         S(int x) : x(x) {}
         const int x;
     };
     int main() {
         std::vector<S> v;
         v.push_back(S(1));
         v.pop_back();
         v.push_back(S(2));
         std::cout << v.data()->x;
     }