On 12/21/20 6:10 PM, Jakub Jelinek wrote:
Hi!
While the gimplifier patch I've just committed fixed an ICE, in some cases
like on the committed testcase cp folding doesn't happen after
build_zero_init_1 because it is called already during gimplification.
Not exactly sure why we just don't call build_zero_cst (type); for the > scalar
types
I don't know either. Want to test that?
, but if we want to use convert, the problem with complex floats
is that it returns a COMPLEX_EXPR with FLOAT_EXPR arguments which have
INTEGER_CST 0 as argument. As fold isn't recursive, it doesn't do anything
in that case, we need to first fold those FLOAT_EXPRs to REAL_CST 0.0 and
only afterwards the COMPLEX_EXPR can be folded into COMPLEX_CST with 0.0
arguments.
The following patch calls cp_fold_rvalue in that case which does the
recursive folding.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2020-12-21 Jakub Jelinek <ja...@redhat.com>
PR c++/98353
* init.c (build_zero_init_1): Use cp_fold_rvalue instead of fold
for SCALAR_TYPE_P zero initializers.
--- gcc/cp/init.c.jj 2020-12-09 09:03:38.270054654 +0100
+++ gcc/cp/init.c 2020-12-21 13:51:57.353332652 +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;
Jakub
