[Bug c++/99705] New: [10/11 Regression] ICE in expand_expr_real_1 since r10-3661

[Bug c++/99705] New: [10/11 Regression] ICE in expand_expr_real_1 since r10-3661

[jakub at gcc dot gnu.org]

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

            Bug ID: 99705
           Summary: [10/11 Regression] ICE in expand_expr_real_1 since
                    r10-3661
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

template<typename T>
struct C
{
    C() { f(); }
    ~C() {}
    static void f() {}
};

struct X
{
    X();
    int n = 10;
    C<int>* p = new C<int>[n];
};

X::X()
{}

ICEs with -std=c++14 starting with my
r10-3661-g8e007055dd1374ca4c44406a4ead172be0dfa3a8

[Bug c++/99705] [10/11 Regression] ICE in expand_expr_real_1 since r10-3661

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
           Priority|P3                          |P2
   Last reconfirmed|                            |2021-03-22
   Target Milestone|---                         |10.3

[Bug c++/99705] [10/11 Regression] ICE in expand_expr_real_1 since r10-3661

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The *.original dump diff before/after is
@@ -32,11 +32,11 @@
     }
   <D.2413>:;
   {
-    struct C * D.2390;
+    struct C * D.2390 = D.2378 + ((SAVE_EXPR <(sizetype) ((struct X *)
this)->n> - (sizetype) D.2380) + 18446744073709551615);

     (if (D.2378 != 0B)
       {
-        (void) (D.2390 = D.2378 + ((SAVE_EXPR <(sizetype) ((struct X *)
this)->n> - (sizetype) D.2380) + 18446744073709551615));, while (1)
+                struct C * D.2390 = D.2378 + ((SAVE_EXPR <(sizetype) ((struct
X *) this)->n> - (sizetype) D.2380) + 18446744073709551615);, while (1)
           {
             if (D.2390 == D.2378) break;, (void) (D.2390 = D.2390 +
18446744073709551615);;, C<int>::~C (D.2390);;
           };
and I think the problem is that this in the latter comes from the wrong ctor -
_ZN1XC4Ev rather than expected _ZN1XC2Ev.

[Bug c++/99705] [10/11 Regression] ICE in expand_expr_real_1 since r10-3661

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 50447
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50447&action=edit
gcc11-pr99705.patch

One possible fix.  The reason I've made the build_vec_delete_1 changes was that
P0784R7 was implemented some months before P1331R2 and therefore the artificial
tbase var without initializer was rejected during constexpr evaluation, but now
it is not anymore.

[Bug c++/99705] [10/11 Regression] ICE in expand_expr_real_1 since r10-3661

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 50449
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50449&action=edit
gcc11-pr99705-2.patch

Another untested fix instead of the above.

[Bug c++/99705] [10/11 Regression] ICE in expand_expr_real_1 since r10-3661

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 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:6081d8994ed1a0aef6b7f5fb34f091faa3580416

commit r11-7844-g6081d8994ed1a0aef6b7f5fb34f091faa3580416
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 26 09:35:26 2021 +0100

    c++: Fix ICE with nsdmi [PR99705]

    When adding P0784R7 constexpr new support, we still didn't have
    P1331R2 implemented and so I had to change also build_vec_delete_1
    - instead of having uninitialized tbase temporary later initialized
    by MODIFY_EXPR I've set the DECL_INITIAL for it - because otherwise
    it would be rejected during constexpr evaluation which didn't like
    uninitialized vars.  Unfortunately, that change broke the following
    testcase.
    The problem is that these temporaries (not just tbase but tbase was
    the only one with an initializer) are created during NSDMI parsing
    and current_function_decl is NULL at that point.  Later when we
    clone body of constructors, auto_var_in_fn_p is false for those
    (as they have NULL DECL_CONTEXT) and so they aren't duplicated,
    and what is worse, the DECL_INITIAL isn't duplicated either nor processed,
    and during expansion we ICE because the code from DECL_INITIAL of that
    var refers to the abstract constructor's PARM_DECL (this) rather than
    the actual constructor's one.

    So, either we can just revert those build_vec_delete_1 changes (as done
    in the second patch - in attachment), or, as the first patch does, we can
    copy the temporaries during bot_manip like we copy the temporaries of
    TARGET_EXPRs.  To me that looks like a better fix because e.g. if
    break_out_of_target_exprs is called for the same NSDMI multiple times,
    sharing the temporaries looks just wrong to me.  If the temporaries
    are declared as BIND_EXPR_VARS of some BIND_EXPR (which is the case
    of the tbase variable built by build_vec_delete_1 and is the only way
    how the DECL_INITIAL can be walked by *walk_tree*), then we need to
    copy it also in the BIND_EXPR BIND_EXPR_VARS chain, other temporaries
    (those that don't need DECL_INITIAL) often have just DECL_EXPR and no
    corresponding BIND_EXPR.
    Note, ({ }) are rejected in nsdmis, so all we run into are temporaries
    the FE creates artificially.

    2021-03-26  Jakub Jelinek  <jakub@redhat.com>

            PR c++/99705
            * tree.c (bot_manip): Remap artificial automatic temporaries
mentioned
            in DECL_EXPR or in BIND_EXPR_VARS.

            * g++.dg/cpp0x/new5.C: New test.

[Bug c++/99705] [10 Regression] ICE in expand_expr_real_1 since r10-3661

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[10/11 Regression] ICE in   |[10 Regression] ICE in
                   |expand_expr_real_1 since    |expand_expr_real_1 since
                   |r10-3661                    |r10-3661

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.

[Bug c++/99705] [10 Regression] ICE in expand_expr_real_1 since r10-3661

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:1c82b47137ab4212b7618da3458d2949b2dff1a3

commit r10-9623-g1c82b47137ab4212b7618da3458d2949b2dff1a3
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 26 09:35:26 2021 +0100

    c++: Fix ICE with nsdmi [PR99705]

    When adding P0784R7 constexpr new support, we still didn't have
    P1331R2 implemented and so I had to change also build_vec_delete_1
    - instead of having uninitialized tbase temporary later initialized
    by MODIFY_EXPR I've set the DECL_INITIAL for it - because otherwise
    it would be rejected during constexpr evaluation which didn't like
    uninitialized vars.  Unfortunately, that change broke the following
    testcase.
    The problem is that these temporaries (not just tbase but tbase was
    the only one with an initializer) are created during NSDMI parsing
    and current_function_decl is NULL at that point.  Later when we
    clone body of constructors, auto_var_in_fn_p is false for those
    (as they have NULL DECL_CONTEXT) and so they aren't duplicated,
    and what is worse, the DECL_INITIAL isn't duplicated either nor processed,
    and during expansion we ICE because the code from DECL_INITIAL of that
    var refers to the abstract constructor's PARM_DECL (this) rather than
    the actual constructor's one.

    So, either we can just revert those build_vec_delete_1 changes (as done
    in the second patch - in attachment), or, as the first patch does, we can
    copy the temporaries during bot_manip like we copy the temporaries of
    TARGET_EXPRs.  To me that looks like a better fix because e.g. if
    break_out_of_target_exprs is called for the same NSDMI multiple times,
    sharing the temporaries looks just wrong to me.  If the temporaries
    are declared as BIND_EXPR_VARS of some BIND_EXPR (which is the case
    of the tbase variable built by build_vec_delete_1 and is the only way
    how the DECL_INITIAL can be walked by *walk_tree*), then we need to
    copy it also in the BIND_EXPR BIND_EXPR_VARS chain, other temporaries
    (those that don't need DECL_INITIAL) often have just DECL_EXPR and no
    corresponding BIND_EXPR.
    Note, ({ }) are rejected in nsdmis, so all we run into are temporaries
    the FE creates artificially.

    2021-03-26  Jakub Jelinek  <jakub@redhat.com>

            PR c++/99705
            * tree.c (bot_manip): Remap artificial automatic temporaries
mentioned
            in DECL_EXPR or in BIND_EXPR_VARS.

            * g++.dg/cpp0x/new5.C: New test.

[Bug c++/99705] [10 Regression] ICE in expand_expr_real_1 since r10-3661

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 10.3 too.