On 7/23/25 11:45 AM, Iain Sandoe wrote:
This is needed to be able to back-port the rest of the CWG2563 work to
GCC-15.2, so I've prioritised it. So far, tested on x86_64 darwin, OK
for trunk (and backport) if it passes wider testing?
thanks
Iain
--- 8< ---
The current implementation was returning the result of the g_r_o_o_a_f
call independently of the return expressions for 'normal' cases.
This prevents the NVRO that we need to guarantee copy elision for the
ramp return values - when these are initialised from a temporary of the
same type.
We should check (gcc_checking_assert?) that NRVO works in the case where
we expect it to, rather than let NRVO failures show up as wrong-code.
The solution here:
- pushes the g_r_o to the outermost scope of the ramp and makes it auto
- updates the type when we know it (after initialising the promise etc)
- in the case that the allocation fails, and we have a g_r_o_o_a_f, we
then determine if the type of the g_r_o is the same as the type of the
ramp return. If this is the case, then we must initialize the g_r_o
from the g_r_o_o_a_f (and the process will fail if this is not well
formed). In the case that the types of the ramp return and the g_r_o
differ then there is no copy elision and we can just use the normal
return machinery to return the g_r_o_o_a_f.
I think it should be simpler/cleaner to move the grooaf case to the
'else' rather than the 'then', to accommodate the NRVO limitation
described in check_return_expr:
So, if this is a value-returning function that always returns the same
local variable, remember it.
We choose the first suitable variable even if the function sometimes
returns something else, but only if the variable is out of scope at the
other return sites, or else we run the risk of clobbering the variable we
chose if the other returned expression uses the chosen variable somehow.
We don't currently do this if the first return is a non-variable, as it
would be complicated to determine whether an NRV selected later was in
scope at the point of the earlier return. We also don't currently support
multiple variables with non-overlapping scopes (53637).
Jason
