[Bug c++/98353] [9/10/11 Regression] ICE in propagate_necessity, at tree-ssa-dce.c:1053 since r6-4886-gcda0a029f45d20f4

[jakub at gcc dot gnu.org]

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.