[Bug c++/121445] [13/14/15 Regression] ICE in build_data_member_initialization when compiling constexpr constructor with nested non-literal types (C++23) since r5-5013

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:5ef6443cc80fe6f8419095a6bcba533a356cd22e

commit r15-10578-g5ef6443cc80fe6f8419095a6bcba533a356cd22e
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Nov 21 14:17:01 2025 +0100

    c++: Fix up build_data_member_initialization [PR121445]

    The following testcase ICEs, because the constexpr ctor in C++14
    or later doesn't contain any member initializers and so the
    massage_constexpr_body -> build_constexpr_constructor_member_initializers
    -> build_data_member_initialization member initialization discovery
    looks at the ctor body instead.  And while it has various
    cases where it punts, including COMPONENT_REF with a VAR_DECL as first
    operand on lhs of INIT_EXPR, here there is COMPONENT_REF with
    several COMPONENT_REFs and VAR_DECL only inside the innermost.

    The following patch makes sure we punt on those as well, instead of
    blindly assuming it is anonymous union member initializer or asserting
    it is a vtable store.

    An alternative to this would be some flag on the INIT_EXPRs created
    by perform_member_init and let build_data_member_initialization inspect
    only INIT_EXPRs with that flag set.

    2025-11-21  Jakub Jelinek  <jakub@redhat.com>

            PR c++/121445
            * constexpr.cc (build_data_member_initialization): Just return
            false if member is COMPONENT_REF of COMPONENT_REF with
            VAR_P get_base_address.

            * g++.dg/cpp1y/constexpr-121445.C: New test.

    (cherry picked from commit 0ac5a60c37d9a40e8993b8207e904b713e73b5d3)