diff mbox series

c++: Fix up floating point complex handling in build_zero_init_1 [PR98353]

Message ID 20201221231053.GJ3788@tucnak
State New
Headers show
Series c++: Fix up floating point complex handling in build_zero_init_1 [PR98353] | expand

Commit Message

Jakub Jelinek Dec. 21, 2020, 11:10 p.m. UTC 
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, 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  <jakub@redhat.com>

	PR c++/98353
	* init.c (build_zero_init_1): Use cp_fold_rvalue instead of fold
	for SCALAR_TYPE_P zero initializers.


	Jakub

Comments

Jason Merrill Dec. 22, 2020, 2:56 p.m. UTC | #1 
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  <jakub@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
>
diff mbox series

Patch

--- 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;