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

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

https://gcc.gnu.org/g:d91b6c93f98cac71f5588d73191d08ad788e600c

commit r15-2920-gd91b6c93f98cac71f5588d73191d08ad788e600c
Author: Marek Polacek <pola...@redhat.com>
Date:   Fri Aug 9 16:14:18 2024 -0400

    c++: ICE with NSDMIs and fn arguments [PR116015]

    The problem in this PR is that we ended up with

      {.rows=(&<PLACEHOLDER_EXPR struct Widget>)->n,
       .outer_stride=(&<PLACEHOLDER_EXPR struct MatrixLayout>)->rows}

    that is, two PLACEHOLDER_EXPRs for different types on the same level
    in one { }.  That should not happen; we may, for instance, neglect to
    replace a PLACEHOLDER_EXPR due to CONSTRUCTOR_PLACEHOLDER_BOUNDARY on
    the constructor.

    The same problem happened in PR100252, which I fixed by introducing
    replace_placeholders_for_class_temp_r.  That didn't work here, though,
    because r_p_for_c_t_r only works for non-eliding TARGET_EXPRs: replacing
    a PLACEHOLDER_EXPR with a temporary that is going to be elided will
    result in a crash in gimplify_var_or_parm_decl when it encounters such
    a loose decl.

    But leaving the PLACEHOLDER_EXPRs in is also bad because then we end
    up with this PR.

    TARGET_EXPRs for function arguments are elided in gimplify_arg.  The
    argument will get a real temporary only in get_formal_tmp_var.  One
    idea was to use the temporary that is going to be elided anyway, and
    then replace_decl it with the real object once we get it.  But that
    didn't work out: one problem is that we elide the TARGET_EXPR for an
    argument before we create the real temporary for the argument, and
    when we get it, the context that this was a TARGET_EXPR for an argument
    has been lost.  We're also in the middle end territory now, even though
    this is a C++-specific problem.

    A solution is to simply stop eliding TARGET_EXPRs whose initializer is
    a CONSTRUCTOR.  Such copies can't be (at the moment) elided anyway.  But
    not eliding all TARGET_EXPRs would be a pessimization.

            PR c++/116015

    gcc/cp/ChangeLog:

            * call.cc (convert_for_arg_passing): Don't set_target_expr_eliding
            when the TARGET_EXPR initializer is a CONSTRUCTOR.

    gcc/ChangeLog:

            * gimplify.cc (gimplify_arg): Do not strip a TARGET_EXPR whose
            initializer is a CONSTRUCTOR.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp1y/nsdmi-aggr23.C: New test.

Reply via email to