Hi Matthew, I think it's worth submitting a core issue, so the Core Working Group can discuss whether there's a defect in which the rule is too strict. You can do so here: https://github.com/cplusplus/CWG/issues

The missing definition for "obtained, directly or indirectly, from the constructor's `this` pointer" should also be reported as a separate core issue.

On Mon, Dec 26, 2022 at 11:22 AM Matthew House via Std-Discussion <std-discussion@lists.isocpp.org> wrote:
On Mon, Dec 26, 2022 at 7:05 AM Thiago Macieira via Std-Discussion
<std-discussion@lists.isocpp.org> wrote:
> FYI, Arthur filed a bug against GCC at
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108216

Ah, then perhaps my concern isn't so independent after all: reading
that bug (and the linked bugs) is what prompted me to take a closer
look at [basic.life] and [class.cdtor] in the first place.

> The original question in #standardese was this source code:
> struct A {
>     virtual void f();
> };
> struct B : virtual A {};
> struct C : virtual A {
>     C(B* p) {
>         A* q = p; // <---
>     }
> };
> struct D : B, C {
>     D(): C(this) {}
> };
> Which when compiled with GCC does produce a nonsensical pointer
> (it's just over 4 MB away from where it should be, on testing).
> Clang seems to be similarly affected, but only if the bases aren't
> empty).
> And yet everyone who looks at this code says that it looks correct
> and valid.

For what it's worth, that code is also correct and valid by my own
reading. Converting this from D* to B* is valid since there are no
other bases between the two types (11.9.5 [class.cdtor] para. 3), and
converting p from B* to A* is valid because the B subobject is within
its lifetime. Perhaps the compilers (and/or the ABIs) are having
trouble with the Standard's implication that each and every base class
subobject, including each virtual base class subobject, must be fully
valid and usable immediately after its constructor returns.
Std-Discussion mailing list

Brian Bi