https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98353
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
On the FE side, I think this can be fixed with:
--- gcc/cp/init.c.jj 2020-12-09 09:03:38.270054654 +0100
+++ gcc/cp/init.c 2020-12-21 13:05:33.137218177 +0100
@@ -187,7 +187,7 @@ build_zero_init_1 (tree type, tree nelts
else if (NULLPTR_TYPE_P (type))
init = build_int_cst (type, 0);
else if (SCALAR_TYPE_P (type))
- init = fold (convert (type, integer_zero_node));
+ init = cp_fold_rvalue (convert (type, integer_zero_node));
else if (RECORD_OR_UNION_CODE_P (TREE_CODE (type)))
{
tree field;
It is unclear to me why it uses so arcane way of emitting zero constants, can't
just build_zero_cst (type); do that?, but if it has to, the complex types can't
be handled by simple fold as fold is not recursive, and convert emits
COMPLEX_EXPR with FLOAT_EXPR of 0 operands, so one needs to fold those operands
and only then fold the COMPLEX_EXPR.
I guess there is some bug on the gimplifier side too, it shouldn't ICE even
when such COMPLEX_EXPRs are not simplified.
