https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88690
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target|arm-linux-gnueabihf |
CC| |jason at gcc dot gnu.org
Host|x86_64-pc-linux-gnu |
Summary|[7/8/9 Regression] internal |[7/8/9 Regression] c++17
|compiler error: in |internal compiler error: in
|output_constructor_regular_ |output_constructor_regular_
|field, at varasm.c:5031 |field, at varasm.c:5031
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And it ICEs everywhere.
The CONSTRUCTOR with D type is:
{.D.2084={.b=0}, .D.2085={}}
D.2084 FIELD_DECL has field offset 0 and size 4 bytes, D.4405 FIELD_DECL has
field offset also 0 and size 0. If that is correct, then the CONTRUCTOR should
be ordered {.D.2085={}, .D.2084={.b=0}}.
.D.2084 is created by build_base_field_1 with t D and base_type B and .D.2085
is created by build_base_field_1 with t D and base_type C.
The latter is created with:
if (cxx_dialect >= cxx17 && !BINFO_VIRTUAL_P (binfo))
{
tree decl = build_base_field_1 (t, basetype, next_field);
DECL_FIELD_OFFSET (decl) = BINFO_OFFSET (binfo);
DECL_FIELD_BIT_OFFSET (decl) = bitsize_zero_node;
SET_DECL_OFFSET_ALIGN (decl, BITS_PER_UNIT);
}
Shall we sort somewhere the FIELD_DECLs by ascending offsets, something else?
