[Bug c++/103991] [12 Regression] Bogus -Wreturn-type with constexpr if and local var with destructor

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 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:cbf06187d5f246634272e3d2892501563bff3d99

commit r12-6579-gcbf06187d5f246634272e3d2892501563bff3d99
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Jan 14 12:09:19 2022 +0100

    c++: Avoid some -Wreturn-type false positives with const{expr,eval} if
[PR103991]

    The changes done to genericize_if_stmt in order to improve
    -Wunreachable-code* warning (which Richi didn't actually commit
    for GCC 12) are I think fine for normal ifs, but for constexpr if
    and consteval if we have two competing warnings.
    The problem is that we replace the non-taken clause (then or else)
    with void_node and keep the if (cond) { something } else {}
    or if (cond) {} else { something }; in the IL.
    This helps -Wunreachable-code*, if something can't fallthru but the
    non-taken clause can, we don't warn about code after it because it
    is still (in theory) reachable.
    But if the non-taken branch can't fallthru, we can get false positive
    -Wreturn-type warnings (which are enabled by default) if there is
    nothing after the if and the taken branch can't fallthru either.

    One possibility to fix this is revert at least temporarily
    to the previous behavior for constexpr and consteval if, yes, we
    can get false positive -Wunreachable-code* warnings but the warning
    isn't present in GCC 12.
    The patch below implements that for constexpr if which throws its
    clauses very early (either during parsing or during instantiation),
    and for consteval if it decides based on block_may_fallthru on the
    non-taken (for constant evaluation only) clause - if the non-taken
    branch may fallthru, it does what you did in genericize_if_stmt
    for consteval if, if it can't fallthru, it uses the older way
    of pretending there wasn't an if and just replacing it with the
    taken clause.  There are some false positive risks with this though,
    block_may_fallthru is optimistic and doesn't handle some statements
    at all (like FOR_STMT, WHILE_STMT, DO_STMT - of course handling those
    is quite hard).
    For constexpr if (but perhaps for GCC 13?) we could try to
    block_may_fallthru before we throw it away and remember it in some
    flag on the IF_STMT, but am not sure how dangerous would it be to call
    it on the discarded stmts.  Or if it is too dangerous e.g. just
    remember whether the discarded block of consteval if wasn't present
    or was empty, in that case assume fallthru, and otherwise assume
    it can't fallthru (-Wunreachable-code possible false positives).

    2022-01-14  Jakub Jelinek  <jakub@redhat.com>

            PR c++/103991
            * cp-objcp-common.c (cxx_block_may_fallthru) <case IF_STMT>: For
            IF_STMT_CONSTEXPR_P with constant false or true condition only
            check if the taken clause may fall through.
            * cp-gimplify.c (genericize_if_stmt): For consteval if, revert
            to r12-5638^ behavior if then_ block can't fall through.  For
            constexpr if, revert to r12-5638^ behavior.

            * g++.dg/warn/Wreturn-type-13.C: New test.