[Bug tree-optimization/109945] Escape analysis hates copy elision: different result with -O1 vs -O2

["redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945

--- Comment #25 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #9)
> struct Widget {
>     int i;
>     int a[4];
> };
> Widget *global = 0;
> Widget make2() { Widget w; w.i = 1; 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?  
> }
> ```
> 
> But does w go out of the scope at the end of make2?

Yes. This example has undefined behaviour in all versions of C++.

w is a local variable, its lifetime is the function body of make2, and global
becomes an invalid pointer after make2 returns, so dereferencing global in g()
is UB.

> Similar question to make
> in the original testcase, does the temp go out of scope?

Before C++17 yes, it was undefined for exactly the same reasons.

That changed in C++17 and now a temporary is not "materialized" until as late
as possible. In many cases there would be no temporary, the prvalue returned by
make() would initialize w in main without any intermediate temporary.

However, [class.temporary] p3 explicitly allows the compiler to create a
temporary object when returning a class with a trivial copy constructor and
trivial (or deleted) destructor. This is permitted precisely to allow what the
x86_64 ABI requires: the return value is passed in registers. Completely
eliding the creation and copy of a temporary would have required an ABI break.

So the example in comment 0 is also an incorrect program, even in C++17. It's
unspecified whether the prvalue created in make() is only materialized when
constructing w (so there is never any temporary Widget) or whether the prvalue
is materialized to a temporary which then gets copied to w using the trivial
copy constructor.

Since it's unspecified, the program cannot rely on any particular behaviour.
The 'global' pointer might point to w, or it might point to a temporary which
has gone out of scope, and in the latter case, dereferencing it in g() is UB.

So inconsistent behaviour with different optimization settings and/or noipa
attributes seems fine. Either global == &w or the program has UB.

I think this is INVALID.