On Wed, Apr 10, 2024 at 07:10:52PM +0200, Richard Biener wrote:
> Ah, I saw the bugzilla patches and wanted this version to be sent
> because I think the COMPOUND_EXPR inconsistency is odd. So Jason,
> please still have a look, not necessarily because of the bug
> which can be fixed in multiple ways but because of that COMPOUND_EXPR
> handling oddity (there are already some cases in tsubst_expr that
> explicitly recurse with tsubst_stmt).
I think if COMPOUND_EXPR appears in a context where only expressions but not
statements are allowed (say one of the operands of PLUS_EXPR/MINUS_EXPR/...
and hundreds of other places), then the operands of that COMPOUND_EXPR
shouldn't be statements either, so we should be using tsubst_expr rather
than tsubst_stmt on it for the recursion on the first operand and it should
never return NULL. For statements, it can return NULL when the statement
is acutally emitted with add_stmt and so nothing more needs to be kept.
tsubst_stmt ends with
default:
gcc_assert (!STATEMENT_CODE_P (TREE_CODE (t)));
RETURN (tsubst_expr (t, args, complain, in_decl));
so if something isn't handled by tsubst_stmt, it will handle it using
tsubst_expr. But COMPOUND_EXPR is I think intentionally handled by both.
({ ... }) is handled separately in the STMT_EXPR tsubst_expr case, where
it calls tsubst_stmt after preparing stuff.
Jakub
