https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908
--- Comment #5 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Iain D Sandoe <ia...@gcc.gnu.org>: https://gcc.gnu.org/g:68ee624bc52ba1154040a904db56dd2f9c3af1f6 commit r15-3153-g68ee624bc52ba1154040a904db56dd2f9c3af1f6 Author: Iain Sandoe <i...@sandoe.co.uk> Date: Sun Aug 18 14:54:38 2024 +0100 c++, coroutines: Fix ordering of return object conversions [PR115908]. [dcl.fct.def.coroutine]/7 says: The expression promise.get_return_object() is used to initialize the returned reference or prvalue result object of a call to a coroutine. The call to get_return_object is sequenced before the call to initial_suspend and is invoked at most once. The issue is about when any conversions are carried out if the type of the g_r_o call is not the same as the ramp return. Currently, we have been doing this by materialising the g_r_o return value and passing that to finish_return_expr() which handles the necessary conversions and checks. As the PR shows, this does not work as expected. In the revised version we carry out the work of the conversions when intialising the return slot (with the same facilities that are used by finish_return_expr()). We do this before the call that initiates the coroutine body, satisfying the requirements for one call before initial suspend. The return expression becomes a trivial 'return <retval>'. This simplifies the ramp logic considerably, since we no longer need to keep track of the temporarily-materialised g_r_o value. PR c++/115908 gcc/cp/ChangeLog: * coroutines.cc (cp_coroutine_transform::build_ramp_function): Rework the return value initialisation to initialise the return slot always from get_return_object, even if that implies carrying out conversions to do so. gcc/testsuite/ChangeLog: * g++.dg/coroutines/pr115908.C: New test. Signed-off-by: Iain Sandoe <i...@sandoe.co.uk>
