[Bug c++/115754] [14 Regression] C++26 ICE on constexpr new

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:297ea7e5bb5c4d92cf3fe29182d432694de858cc

commit r14-10445-g297ea7e5bb5c4d92cf3fe29182d432694de858cc
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Jul 2 22:09:58 2024 +0200

    c++: Fix ICE on constexpr placement new [PR115754]

    C++26 is making in P2747R2 paper placement new constexpr.
    While working on a patch for that, I've noticed we ICE starting with
    GCC 14 on the following testcase.
    The problem is that e.g. for the void * to sometype * casts checks,
    we really assume the casts have their operand constant evaluated
    as prvalue, but on the testcase the cast itself is evaluated with
    vc_discard and that means op can end up e.g. a VAR_DECL which the
    later code doesn't like and asserts on.
    If the result type is void, we don't really need the cast operand
    for anything, so can use vc_discard for the recursive call,
    VIEW_CONVERT_EXPR can appear on the lhs, so we need to honor the
    lval but otherwise the patch uses vc_prvalue.
    I'd like to get this patch in before the rest of P2747R2 implementation,
    so that it can be backported to 14.2 later on.

    2024-07-02  Jakub Jelinek  <jakub@redhat.com>
                Jason Merrill  <jason@redhat.com>

            PR c++/115754
            * constexpr.cc (cxx_eval_constant_expression) <case CONVERT_EXPR>:
            For conversions to void, pass vc_discard to the recursive call
            and otherwise for tcode other than VIEW_CONVERT_EXPR pass
vc_prvalue.

            * g++.dg/cpp26/pr115754.C: New test.

    (cherry picked from commit 1250540a98e0a1dfa4d7834672d88d8543ea70b1)