https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #7 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> --- Richard Biener wrote: > Are we using the wrong check or is escaping 'this' > for these kind of classes invoking undefined behavior? Wow, this got a lot of traffic quickly! Sounds like you (Richard, Andrew) are on top of the issue here, where a constructor is involved; but once you start talking about heuristics and checks, I think it would be productive for you two to make sure you're both on the same page with *this* example: // https://godbolt.org/z/Ea43Y65z4 struct Widget { int i = 1; int a[4]; }; Widget *global = nullptr; Widget make2() { Widget w; global = &w; return w; } void g() { global->i = 42; } int main() { Widget w = make2(); int i = w.i; g(); return (i == w.i); // Does this need to be reloaded and // compared? or is it obviously true? } In this case, Widget has no constructors, and I think it would be perfectly defensible for the compiler to say that "global = &w" is not a valid way to escape the address of that prvalue result (even though copy elision will make the w in make() and the w in main() the same object). But do both of *you* have the same answer to that paradox? If you don't, then you might also not agree about what the appropriate heuristic should be in the original case and might end up talking past each other.