[Bug c++/108417] New: [ICE] Crash on aggregate initialization of base class

[Bug c++/108417] New: [ICE] Crash on aggregate initialization of base class

[m.cencora at gmail dot com]

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

            Bug ID: 108417
           Summary: [ICE] Crash on aggregate initialization of base class
           Product: gcc
           Version: 10.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: m.cencora at gmail dot com
  Target Milestone: ---

Code below compiled on any gcc<11 crashes with following output:
during RTL pass: expand
<source>: In function 'Derived ICE_createDerived()':
<source>:37:5: internal compiler error: in assign_temp, at function.c:984
   37 |     };
      |     ^


FWIW it doesn't crash if field 'f3' is removed.

g++ -std=c++17

struct NonTrivial
{
    NonTrivial() = default;
    NonTrivial(const NonTrivial&);
    NonTrivial& operator=(const NonTrivial&);

    char* ptr = nullptr;
};

struct Base
{
   int f1;
   NonTrivial f2;
   int f3;
};

struct Derived : Base
{
   int f4;
};

Derived createDerivedOk()
{
    return Derived{
        Base{},
        0
    };
}

Base createBase();

Derived ICE_createDerived()
{
    return Derived{
        createBase(),
        0
    };
}

[Bug c++/108417] [ICE] Crash on aggregate initialization of base class

[m.cencora at gmail dot com]

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

--- Comment #1 from m.cencora at gmail dot com ---
The problem seems to occur if base class has a tail padding, and derived class
is trying to reuse it to store its members

[Bug c++/108417] [ICE] Crash on aggregate initialization of base class

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |needs-bisection
      Known to fail|                            |10.4.1
   Last reconfirmed|                            |2023-01-16
             Status|UNCONFIRMED                 |NEW
      Known to work|                            |12.2.1
     Ever confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  Note that trunk ICEs differently now:

> ./cc1plus -quiet t.ii -std=c++17
t.ii: In function 'Derived ICE_createDerived()':
t.ii:37:5: internal compiler error: in cp_gimplify_init_expr, at
cp/cp-gimplify.cc:253
   37 |     };
      |     ^
0xd6fb33 cp_gimplify_init_expr
        /home/rguenther/src/trunk/gcc/cp/cp-gimplify.cc:253
0xd709d8 cp_gimplify_expr(tree_node**, gimple**, gimple**)
        /home/rguenther/src/trunk/gcc/cp/cp-gimplify.cc:508
0x15a124e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
        /home/rguenther/src/trunk/gcc/gimplify.cc:16269
0x157517f gimplify_stmt(tree_node**, gimple**)
        /home/rguenther/src/trunk/gcc/gimplify.cc:7219
0x155e516 gimplify_and_add(tree_node*, gimple**)
        /home/rguenther/src/trunk/gcc/gimplify.cc:492
0x156d62c gimplify_init_ctor_eval
        /home/rguenther/src/trunk/gcc/gimplify.cc:5019
...

253             gcc_checking_assert (TARGET_EXPR_ELIDING_P (from));

needs bisecting for the fix and the new breakage (and possibly splitting).

[Bug c++/108417] [ICE] Crash on aggregate initialization of base class

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=93711

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I am 99% sure this is the same issue as pr98995 even though this is a crash.
The ice is the same as PR  93711.

This code has both an abi issue against it filed and a c++ defect report filed
against it.

[Bug c++/108417] [ICE] Crash on aggregate initialization of base class

[m.cencora at gmail dot com]

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

--- Comment #4 from m.cencora at gmail dot com ---
(In reply to Andrew Pinski from comment #3)
> I am 99% sure this is the same issue as pr98995 even though this is a crash.
> The ice is the same as PR  93711.
> 
> This code has both an abi issue against it filed and a c++ defect report
> filed against it.

I think this is a separate issue.

Here the 'NonTrivial' class is copyable, so even if compiler cannot perform
copy ellision (due to ABI or etc), it should be able to initialize the base
object.

[Bug c++/108417] [ICE] Crash on aggregate initialization of base class

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=90254

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note in c++17 the copy is required to be elision away. And the frontend is
doing that but messing up. The problems are all related really. The question
comes should they be elision away or not and that is what the c++ defect report
is about and the same way the abi issue is about.

[Bug c++/108417] [ICE] Crash on aggregate initialization of base class

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-bisection             |ABI, ice-checking,
                   |                            |ice-on-valid-code
      Known to work|12.2.1                      |

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> Confirmed.  Note that trunk ICEs differently now:
> 
> 253             gcc_checking_assert (TARGET_EXPR_ELIDING_P (from));

That assert is turned off for release checking ....

There is no different ICE on the trunk, just the same one. And again this is
exactly same as those other issues except still ICE instead of rejects valid:

This language/ABI issue is tracked at https://wg21.link/cwg2403 and
https://github.com/itanium-cxx-abi/cxx-abi/issues/107

[Bug c++/108417] [ICE] Crash on aggregate initialization of base class

[m.cencora at gmail dot com]

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

--- Comment #7 from m.cencora at gmail dot com ---
Hmm, ok.
So if I wanted to workaround this in generic code, what kind of types should I
exclude from aggregate initialization? Any type that has a base class with a
tail padding? Or just the last direct base cannot have tail padding?

Also ICE-ing is not very user friendly, maybe we could use move/copy-ctor
anyway for such a non-trivial base (similarly to what clang does) or at least
error-out with a nice message.