[Bug c++/112619] [14 regression] ICE when building libcrafter (tree check: expected statement_list, have modify_expr in tsi_start, at tree-iterator.h:57) since r14-5086-gae07265381d934

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

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:1c44bd92a86db3fcdeb4a66ce2f3222d13af0681

commit r14-5814-g1c44bd92a86db3fcdeb4a66ce2f3222d13af0681
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Nov 24 08:44:28 2023 +0100

    tree: Fix up try_catch_may_fallthru [PR112619]

    The following testcase ICEs with -std=c++98 since r14-5086 because
    block_may_fallthru is called on a TRY_CATCH_EXPR whose second operand
    is a MODIFY_EXPR rather than STATEMENT_LIST, which try_catch_may_fallthru
    apparently expects.
    I've been wondering whether that isn't some kind of FE bug and whether
    there isn't some unwritten rule that second operand of TRY_CATCH_EXPR
    must be a STATEMENT_LIST.  Looking at the FEs, the C++ FE uses mostly its
    own trees, TRY_BLOCK (TRY_CATCH_EXPR replacement) with HANDLER in it
(CATCH_EXPR
    replacement) - but HANDLER can be immediate second operand rather than
nested
    in STATEMENT_LIST, EH_SPEC_BLOCK (this one stands for both TRY_CATCH_EXPR
    and EH_FILTER_EXPR in its second argument); both of these are only replaced
    by the generic trees during gimplification though, so will unlikely be seen
    by block_may_fallthru; and then CLEANUP_STMT, which is genericized
    into TRY_CATCH_EXPR with non-CATCH_EXPR/EH_FILTER_EXPR in its body (this is
    the one that causes the ICE on this testcase).
    The Go and Rust FEs create TRY_CATCH_EXPR with CATCH_EXPR immediately in
its
    second argument (but either are unlucky that block_may_fallthru isn't
called
    or the body can always fallthru, or latent ICE), while the D FE most likely
    hit this ICE and attempts to work around it, by checking at TRY_CATCH_EXPR
    creation time if the second argument from pop_stmt_list is STATEMENT_LIST
and
    if not, forcefully wraps it into a STATEMENT_LIST.

    Unfortunately, I don't see an easy way to create an artificial tree
iterator
    from just a single tree statement, so the patch duplicates what the loops
    later do (after all, it is very simple, just didn't want to duplicate
    also the large comments explaning it, so the 3 See below. comments).

    2023-11-24  Jakub Jelinek  <jakub@redhat.com>

            PR c++/112619
            * tree.cc (try_catch_may_fallthru): If second operand of
            TRY_CATCH_EXPR is not a STATEMENT_LIST, handle it as if it was a
            STATEMENT_LIST containing a single statement.

            * g++.dg/eh/pr112619.C: New test.