[Bug c++/111660] [14 Regression] Compilation of constexpr function returning enum takes exponential time with -std=c++2a since r14-4140-g6851e3423c2b5e

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

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Marek Polacek <mpolacek@gcc.gnu.org>:

https://gcc.gnu.org/g:765c3b8f82d50961008c214ac2113f35e7532aa9

commit r14-4693-g765c3b8f82d50961008c214ac2113f35e7532aa9
Author: Marek Polacek <polacek@redhat.com>
Date:   Thu Oct 12 15:58:05 2023 -0400

    c++: Fix compile-time-hog in cp_fold_immediate_r [PR111660]

    My recent patch introducing cp_fold_immediate_r caused exponential
    compile time with nested COND_EXPRs.  The problem is that the COND_EXPR
    case recursively walks the arms of a COND_EXPR, but after processing
    both arms it doesn't end the walk; it proceeds to walk the
    sub-expressions of the outermost COND_EXPR, triggering again walking
    the arms of the nested COND_EXPR, and so on.  This patch brings the
    compile time down to about 0m0.030s.

    The ff_fold_immediate flag is unused after this patch but since I'm
    using it in the P2564 patch, I'm not removing it now.  Maybe at_eof
    can be used instead and then we can remove ff_fold_immediate.

            PR c++/111660

    gcc/cp/ChangeLog:

            * cp-gimplify.cc (cp_fold_immediate_r) <case COND_EXPR>: Don't
            handle it here.
            (cp_fold_r): Handle COND_EXPR here.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp0x/hog1.C: New test.
            * g++.dg/cpp2a/consteval36.C: New test.