https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126420
--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <[email protected]>: https://gcc.gnu.org/g:72fba287f32b4a86c55c24b475de891fc88de217 commit r17-2841-g72fba287f32b4a86c55c24b475de891fc88de217 Author: Jakub Jelinek <[email protected]> Date: Fri Jul 31 08:47:54 2026 +0200 c++: Fix up check_return_expr for expansion stmts [PR126420] The first testcase below is rejected because of a deduction failure, the second testcase ICEs. The first testcase is IFNDR according to https://eel.is/c++draft/temp.res.general#6.2 - no valid specialization, ignoring static_assert-declarations that fail, can be generated for the compound-statement of an expansion-statement and there is no instantiation of it, so rejecting it is fine and accepting it silently too. But we ICE on the second testcase and that is a problem, we set current_function_returns_value = 1 in check_return_expr when the return value is dependent, and then don't instantiate it, and as it is the only return from the function, when we try to expand it we try to create dependent RESULT_DECL etc. for it and ICE. The following patch just defers what check_return_expr normally does in expansion statement bodies. For expansion statement not within a template check_return_expr will be called again when we try to instantiate the body (if at all), similarly for partial specialization we don't try to find out if the expansion stmt has constant number of iterations at that point and will invoke check_return_expr again during the final instantiation. 2026-07-30 Jakub Jelinek <[email protected]> PR c++/126420 PR c++/126423 * typeck.cc (check_return_expr): If in_expansion_stmt, goto dependent before even setting current_function_returns_value. * pt.cc (tsubst_stmt): Temporarily set in_expansion_stmt around partial instantiation of expansion statement body. * g++.dg/cpp26/expansion-stmt43.C: New test. * g++.dg/cpp26/expansion-stmt44.C: New test. Reviewed-by: Jason Merrill <[email protected]>
